Comment by tobias3
8 years ago
I'd say the main problem is that there isn't a fsck for ZFS. If important metadata gets damaged you'll have to re-create the whole file system.
W.r.t. to btrfs they are at least working on a fsck tool, even though it can't repair much yet (what it can repair is e.g. some bitflips caused by bad RAM: https://patchwork.kernel.org/patch/4116411/ ).
And stuff like ext4 or ntfs can get back to a state where one can write to it again in most cases.
Another problem is that many applications don't handle EIO well, i.e. they don't give you an option like "Continue with corrupt data", e.g. if a video file gets damaged it doesn't matter much, it'll just be a few damaged pixels, but the whole video player stops playback because it doesn't handle the IO error.
If there is any kind of corruption on a Btrfs file system, it will report EIO and path to the corrupt file, it will not handoff corrupt data to user space. The application can't really do that much but say something like I/O error, check kernel messages, or some such. It can't ask the kernel to continue with corrupt data, Btrfs driver has no such option.
Also, if metadata gets damaged, there is an option to roll back the filesystem to an earlier transaction using "zpool import -F".