4 ms·

I'm not aware of ZFS letting you access corrupted files that easily, the Oracle manual [1] notes that files can only be recovered from backup or removed, not ho

by tscs37 9y ago

I'm not aware of ZFS letting you access corrupted files that easily, the Oracle manual [1] notes that files can only be recovered from backup or removed, not how to access a file that has been corrupted. So this does seem to imply that ZFS does indeed throw away data if it's corrupted. Of course a user would rather know about corruption, but on the average user system with family pictures, you don't run into problems even after years to my experience. The photos function perfectly fine with minor corruption, which as noted above, does not work on ZFS since on ZFS it's either perfect or repairable or lost. >I've explicitly said that snapshots HELPS with backups, not that they are backups. You can do Snapshots on other FS' too, LVM and dattobd allow Snapshots of Blockdevices fairly easily. So I still don't see why that makes ZFS superior to ext4 when you can simply layer the solution underneath. Also, btw, LVM has RAID1 and RAID6, both of which allow the user to detect data corruption on any filesystem, which IMO, is better than restricting to one filesystem. That way you can make an image of an old FAT16 device and be assured that it won't suddenly corrupt data. Same goes for mdraid and snapraid, the later of which is a file-based solution and allows recovery of data beyond loosing all parity of an array plus additional drives. ZFS does to my knowledge not work well once you loose more than it tolerates. Why choose ZFS when I can layer the solution together? Or rather, layer until a FS with a better underlying design comes around. [1]: https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html

tjoff 9y ago
LVM and dattobd are not equivalent and only have some overlap in usability and often come with severe limitations and implications in practice. ZFS is targeted towards the enterprise and such is adapted for that use case. I agree that it isn't perfect for home users and I'm not advocating that ZFS be the acceptable solution. I'm just stating that Linux does not have a decent general purpose filesystem. There is nothing that says that a checksum mismatch results in data loss, that statement is absurd. ZFS has the stance that you should not work on corrupted data as that will result in further corruption when action are based upon it. I tend to agree with that approach, but ZFS will not remove the data it finds corrupted. You can also layer a more traditional filesystem upon ZFS to leverage redundancy, checksumming and snapshots, something that mdadm does not provide. There are very good reasons for why a layered approach isn't nearly as flexible, this was controversial at the time and debated alot a decade ago. Most RAID solutions don't even verify the data when read from normal operations. A checksummed approach is a significant improvement, in combination with redundant information you can automatically recover - something that is hard to do in a layered approach. Also, with with a checksum you can verify the correct result. With raid 5 or degraded raid 6 you can at best know that an error has occured but not fix it. Again something that a layered approach has issues with (even if the filesystem had checksumming the RAID controller/software wouldn't know or be able to act upon it).

by tscs37 9y ago

tjoff 9y ago

LVM and dattobd are not equivalent and only have some overlap in usability and often come with severe limitations and implications in practice. ZFS is targeted towards the enterprise and such is adapted for that use case. I agree that it isn't perfect for home users and I'm not advocating that ZFS be the acceptable solution. I'm just stating that Linux does not have a decent general purpose filesystem. There is nothing that says that a checksum mismatch results in data loss, that statement is absurd. ZFS has the stance that you should not work on corrupted data as that will result in further corruption when action are based upon it. I tend to agree with that approach, but ZFS will not remove the data it finds corrupted. You can also layer a more traditional filesystem upon ZFS to leverage redundancy, checksumming and snapshots, something that mdadm does not provide. There are very good reasons for why a layered approach isn't nearly as flexible, this was controversial at the time and debated alot a decade ago. Most RAID solutions don't even verify the data when read from normal operations. A checksummed approach is a significant improvement, in combination with redundant information you can automatically recover - something that is hard to do in a layered approach. Also, with with a checksum you can verify the correct result. With raid 5 or degraded raid 6 you can at best know that an error has occured but not fix it. Again something that a layered approach has issues with (even if the filesystem had checksumming the RAID controller/software wouldn't know or be able to act upon it).