On 10/17/07, Kevan Benson <kbenson@xxxxxxxxxxxxxxx> wrote: > The rsync case can probably be handled through a separate find of the > appropriate attributes on the source and set on the target. A simple > bash/perl script could handle this in a few lines. > > The fsck case is more interesting, but if you could get fsck to report > file/directory names that have problems and not fix them, it's easy to > pipe that to a script to remove the trusted.afr.version attribute on the > files and then the AFR will heal itself. didn't check, may be you know, is the second healthy pair in cluster/stripe (if two bricks are used to stripe) in the case to be copied too? (of course afr'ed volumes use the same underlying cluster/stripe configuration) Checksums would of course give you much better tracking of corrupted > files, but I imagine the cpu strain and speed decrease would make it > non-feasible. yes, it is a paranoia but I said about rsync'ing with --checksum added, metadata of a corrupted file can be correct, so rsync'ing will take more or as much time (two replicas are checksum'ed) as checksum'ing corrupted replica and comparing with checkum kept in an extended attribute(s) Regards, Alexey.
