Uwe Dippel wrote:
Hang on one sec.... Isn't this completely true for ALL filesystems, except that others can't detect that corruption has occurred?Try the thread "ZFS: unreliable for professional usage?" in zfs-discuss for further info, and read how SUN engineers agree to potential corruption without proper umount && export.
So, your suggestion to NOT do it is simply mitigated by just doing a zfs export <poolname> before pulling the drive.Don't. Simply don't. At least not yet, as long as the recovery utility for the Überblocks is pending. Then test-test-test. [i]Provided you've got enough space to create your redundant pools, ZFS is an awesome backup mechanism: 1: You can use zfs send/receive to copy data from your main pool to your backup pool. 2: You can use "incremental" zfs send/receive to only backup the changes. This is REALLY cool. 3: You can turn on compression on your backup pool to reduce the amount of space used. 4: Your data can be read on both SPARC and x64 as ZFS will do the endian translations for you. [/i]True, these are cool. Except, that backups in the first place need to be reliable. And pulling the drive after a umount, forgetting export, can irreversibly destroy all your data.
I don't understand why the rules for ZFS are any different from the rules for any other filesystem. Why don't you try pulling out drives for UFS and pcfs and seeing whether they are corrupted or not? Guess what, they are equally likely to be corrupted, but you simply wont be ablt to detect the corruption.
As I said before, which one would you choose? Silent corruption or being notified that your data is inconsistent?
Uwe
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sysadmin-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
