> 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, Btrfs could repair a Fossil database inflight, and without hiccup? Tell me a little more - it would repair sectors, blocks, segments of the whole Fossil image? Or the whole image? It seems that replacing the whole image would be wrong, and replacing sectors/blocks/segments/sections would be impossible if you want Fossil to not be corrupt in some other way. I wrote that because "data being checksummed" is ambiguous. In summary you're saying that the FS corruption checking and healing is just fine. > 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. I'm confused - you think Fossil doing it's own bitrot/corruption checking/repair is a thing that is possible/good? - Paul
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
