> 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.
Since all I/O in ZFS is cached, this actually isn't that bad; the seek happens eventually, but it's not an "extra" seek. In non-COW file systems, you'd normally have to seek back to the data's original location anyway, since the data is usually written long after the read. There are some potential places where COW costs you performance. How much you see any of these will depend on your application. 1. If you are writing less than a full file system block (128K by default on ZFS, but tunable), ZFS will do a read/modify/write operation. In some cases the read would have been unnecessary, and the write smaller, on a non-COW file system (particularly with direct i/o enabled). If your application does a lot of random writes, it's important to tune the ZFS block size to match. 2. Extra CPU is required to do the allocation of the new block & deallocation of the old block (and the corresponding allocation/deallocation of the inode & indirect blocks). This will generally be visible if you're writing at a relatively high rate. 3. If you have files which are frequently read in large sequential blocks but updated randomly in relatively small blocks, COW will slow down read operations substantially. This is not very common, but shows up in data warehousing environments (database table scans). Anton This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
