ZFS is a copy-on-write filesystem. The important point is that if a single byte in a file is changed then the containing block is rewritten elsewhere, requiring that the file block pointers be rewritten - and when these are rewritten they are likewise written elsewhere and pointers to *them* need to be rewritten, "recursively" all the way to the root of the filesystem, or überblock.
In other words, a write anywhere necessitates changes in high-level filesystem metadata. In an archaic filesystem such as NTFS changes are local: write a file require little metadata be changed and rarely metadata for the entire filesystem. As a result ZFS *is* more prone to pool loss *when the hardware screws up* since filesystem metadata is written more often. At one time there was talk of ZFS implementing a "deferred reallocation" scheme in überblock updates. The would greatly improve ZFS' ability to withstand poorly designed hardware. PS RAIDZ2 is a good thing but is mostly irrelevant to pool corruption. You need backups. I set up all client installations with a hot backup via zfs send/recv. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
