3 ms·
If I recall correctly, ZFS error recovery was still “restore from backup” at the time, and iCloud acceptance was more limited. (ZFS basically gave up if an erro
by fweimer 1y ago
If I recall correctly, ZFS error recovery was still “restore from backup” at the time, and iCloud acceptance was more limited. (ZFS basically gave up if an error was encountered after the checksum showed that the data was read correctly from storage media.) That's fine for deployments where the individual system does not matter (or you have dedicated staff to recover systems if necessary), but phones aren't like that. At least not from the user perspective.
- ryao 1y agoZFS has ditto blocks that allows it to self heal in the case of corrupt metadata as long as a good copy remains (and there would be at least 2 copies by default). ZFS only ever needs you to restore from backup if the damage is so severe that there is no making sense of things. Minor things like the indirect blocks being missing for a regular file only affect that file. Major things like all 3 copies of the MOS (the equivalent to a superblock) being gone for all uberblock entries would require recovery from backup. If all copies of any other filesystem’s superblock were gone too, that filesystem would be equally irrecoverable and would require restoring from backup.
- fweimer 1y agoAs far as I understand it, ditto blocks were only used if the corruption was detected due to checksum mismatch. If the checksum was correct, but metadata turned out to be unusable later (say because it was corrupted in memory, and the the checksum was computed after the corruption happened), that was treated as a fatal error.
- water9 1y agoSo the solution is to use ._ files that most people will delete because they are a nuisance?