On Jul 5, 2016, at 4:55 PM, Paul Hammant <[email protected]> wrote: > > somehow Btrfs or ZFS know Fossil well enough to repair a small section of a > moving target?
Those filesystems don’t need to know Fossil’s internals at all. Self-repair only requires checksums and redundancy. If one checksum doesn’t match the contents of the data being checksummed, another copy of the data is checked, and if its contents match the checksum, it is presumed to be the correct one, so the bad copy is overwritten with it. ZFS and btrfs will do this opportunistically on a data read,[*] or on-demand with the scrub command: https://docs.oracle.com/cd/E23823_01/html/819-5461/gbbwa.html https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub Fossil could do the same by comparing the local copy data against its local checksum, and if that doesn’t match, ask the server it most recently sync’d against for its copy. Incidentally, this is also why People On The Internet Are Being Wrong when they claim it is a problem that Apple’s new APFS filesystem lacks data checksumming. APFS also doesn’t support pools of redundant storage, a la ZFS, which I believe is because Apple doesn’t sell a single device with redundant storage today. Without redundant storage, there’s no especially good reason for APFS to include data checksums since a bad data block can only be rejected, not fixed. The solution is backups, not data checksums. The vast bulk of Apple’s devices sold don’t even have the option of external storage (iPhones, iWatches, etc.), and I’d bet the minority of Apple devices hooked up to external storage are non-redundant, and that the minority of that minority that do have external redundant storage are using some kind of proprietary RAID system, and so couldn’t use APFS even if they wanted to. Those weirdos among us who want to pool JBODs with redundancy and data checksumming on a Mac will continue to use ZFS. It’s no surprise that Apple has chosen not to support this minority of a minority of a minority. [*] Scrub is still better than opportunistic checks because it forces the filesystem to read all copies of all blocks, not just one. That is, if you have a 2-way mirror, I believe both ZFS and btrfs will interleave reads so that half the blocks come from each disk, which speeds the operation up. If there’s a corrupt block on disk 0 but the filesystem chose to read that block from disk 1, the filesystem won’t know the block is corrupt until you try again and somehow cause it to read from disk 0 this time. Scrub forces that to happen for every block. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
