yes, but we can't discuss replicas consistency after afr crash if we skip points which make reasoning wrong. Crash can occur in glfs context only or as a result of powercut, in bouth cases glfs is to restore replicas consistency right. Propose to close the thread, as Krishna said about glfs repairing. The solution with your flag is the best as difference in size and mtime is not exhaustive info about unfinished replica updating in some cases after afr crash. To clean up after powercuts isn't his responsibility but it's a pity he doesn't believe your solution to be better (probably there are more important things). Regards, Alexey. On 10/25/07, Kevan Benson <kbenson@xxxxxxxxxxxxxxx> wrote: > > > As I said, I was referring to atomic in the context of GlusterFS. Using > locks (thread locks in his case), they can easily prevent any other > GlusterFS threads from performing an operation on the file). In that > respect, it's atomic for that file with respect to GlusterFS. Other > processes on the server could of course perform operations at this time, > which makes the operation not TRULY atomic, just atomic for glusterfs on > that file, on that system. Perhaps "atomic" was a bad choice of a word > to convey this. > >
