Chad Mynhier writes: > On 4/27/07, Erblichs <[EMAIL PROTECTED]> wrote: > > Ming Zhang wrote: > > > > > > Hi All > > > > > > I wonder if any one have idea about the performance loss caused by COW > > > in ZFS? If you have to read old data out before write it to some other > > > place, it involve disk seek. > > > > > > > Ming, > > > > Lets take a pro example with a minimal performance > > tradeoff. > > > > All FSs that modify a disk block, IMO, do a full > > disk block read before anything. > > > > Actually, I'd say that this is the main point that needs to be made. > If you're modifying data that was once on disk, that data had to be > read from at some point in the past. This is invariably true for any > filesystem. >
Nits, just so readers are clear about this : the read of old data to service a write, needs only be done when handling a write of a partial filesystem block (and the data is not cached as mentioned). For a fixed size block database with matching ZFS recordsize, then writes will mostly be handled without a need to read previous data. Most FS should behave the same here. > With traditional filesystems, that data block is rewritten in the same > place. If it were the case that disk blocks were always written > immediately after being read, with no intervening I/O to cause a disk > seek, COW would have no performance benefit over traditional > filesystems. (Well, this isn't true, as there are other benefits to > be had.) > > But it's rarely (if ever) the case that this happens. The modified > block is generally written some time after the original block was > read, with plenty of intervening I/O that leaves the disk head over > some randome location on the platter. So for traditional filesystems, > the in-place write of a modified block will typically involve a disk > seek. > > And a second point to be made about this is the effect of caching. > With any filesystem, writes are cached in memory and flushed out to > disk on a regular basis. With traditional filesystems, flushing the > cache involves a set of random writes on the disk, which is possibly > going to involve a disk seek for every block written. (In the best > case, writes could be reordered in ascending order across the disk to > miinimize the disk seeks, but there would still possibly be a small > disk seek between each write.) > > With a COW filesystem, flushing the cache involves writing > sequentially to disk with no intervening disk seeks. (This assumes > that there's enough free space on disk to avoid fragmentation.) In > the ideal case, this means writing to disk at full platter speed. > This is where the main performance benefit of COW comes from. > yep. > Chad Mynhier > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
