On Jun 28, 2016, at 7:50 AM, Paul Hammant <p...@hammant.org> wrote: > > OS/ File system repair of a large image file (such as fossil's) is the way > ahead?
I don’t believe Fossil has any built-in self-repair facilities. It just checks itself for consistency at various points in its operation and refuses to continue if it detects an error. At that point, you’d have to find a copy of the repo that doesn’t have the error and replace the broken copy with it. Karel is right: this is a job for ZFS or similar. (And yes, HAMMER does do data and metadata checksumming, and so should be able to self-repair given enough redundant copies of the data.) Fossil *could* be modified to self-repair. It has the info it needs to do so. But then, why bother in a world where you have things like ZFS, which can protect not only your Fossil repos, but also everything else you hold dear? > I would imagine it better implemented as a fossil background activity > communicating with a replica elsewhere. How is that better than a periodic ZFS scrub? https://docs.oracle.com/cd/E23823_01/html/819-5461/gbbwa.html _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
