3 ms·

I read some time ago that ZFS is definitely NOT the right tool for laptop/external storage, unless you actually have a zpool with mirroring/raidz (which means y

I read some time ago that ZFS is definitely NOT the right tool for laptop/external storage, unless you actually have a zpool with mirroring/raidz (which means you have to always keep the devices connected). The reason is that when ZFS detects corruption, it'll lock down the whole fs... and prevent reading/recovery data from it, as recovering data from raidz is the expected solution in that case. I tried to google again for the description of this issue, but I couldn't find it... I found this otoh: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/VEV-uKUzP14 https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs... And things aren't that obvious, apparently: > Even without redundancy and "zfs set copies", ZFS stores two copies of all metadata far apart on the disk, and three copies of really important zpool wide metadata. Whichn means that this might not actually be a problem after all

Freaky 11y ago
> The reason is that when ZFS detects corruption, it'll lock down the whole fs... and prevent reading/recovery data from it Depends on what exactly is corrupt, but for file corruption it's generally just a case of warnings in logs/zpool status (which will suggest restoring the file from backup), and IO errors trying to access that specific file. The pool itself should remain intact and online. It's less clear cut if it's important metadata that's damaged, but as you mention, ZFS is quite aggressive about maintaining multiple copies even on standalone devices.
ryao 11y ago
> The reason is that when ZFS detects corruption, it'll lock down the whole fs... and prevent reading/recovery data from it, as recovering data from raidz is the expected solution in that case. ZFS has duplicate metadata by default, so it can recover from corrupted metadata blocks unless too much is gone. If the data blocks are corrupted and there is no resundancy, you should get EIO. There is no code to "lock down the FS", although if you have severe damage (like zeroing all copies of important metadata or losing all members of a mirror), it will die and you will see faulted status. That is a situation no storage stack can survive and is why people should have backups.

Freaky 11y ago

> The reason is that when ZFS detects corruption, it'll lock down the whole fs... and prevent reading/recovery data from it Depends on what exactly is corrupt, but for file corruption it's generally just a case of warnings in logs/zpool status (which will suggest restoring the file from backup), and IO errors trying to access that specific file. The pool itself should remain intact and online. It's less clear cut if it's important metadata that's damaged, but as you mention, ZFS is quite aggressive about maintaining multiple copies even on standalone devices.

ryao 11y ago

> The reason is that when ZFS detects corruption, it'll lock down the whole fs... and prevent reading/recovery data from it, as recovering data from raidz is the expected solution in that case. ZFS has duplicate metadata by default, so it can recover from corrupted metadata blocks unless too much is gone. If the data blocks are corrupted and there is no resundancy, you should get EIO. There is no code to "lock down the FS", although if you have severe damage (like zeroing all copies of important metadata or losing all members of a mirror), it will die and you will see faulted status. That is a situation no storage stack can survive and is why people should have backups.