On 10/26/07, Kevan Benson <kbenson@xxxxxxxxxxxxxxx> wrote:
> Krishna Srinivas wrote:
> >>> My thought above was a simple flag as to whether or not the file was
> >>> bing written just to denote whether it should be considered in a
> >>> consistent state if a crash happens.
> >
> > This will not work because, setting the flag before write() and resetting
> > after write() will be expensive interms of cpu cycles (debatable)
> >
> > Also suppose we have set the flag before write(), another client sees
> > that this flag is set on open() and takes wrong action (returning EIO) it is not
> > correct behavior.
>
> I was SO willing to let this thread die at Alexey's suggestion, and you
> had to pull me back in. ;)
>
> I think the simplest solution that Alexey and I came up with was not to
> set the flag before and after write, but before and after open, as in this:
you mean before open and after close? (as given below):
>
> Open() {
> trusted_afr_open=1;
> }
>
> Close() {
> trusted_afr_open=0;
> trusted_afr_version++;
> }
>
>
> So, if the trusted_afr_version is the same across the board but the
> rusted_afr_open attribute is set and NO processes have the file open,
> you know it's possible it could be in an inconsistent state (probably
> only slightly inconsistent, but possible). In that case you would want
> to self-heal from one afr subvolume to the others.
So during open(), if version is same if the trusted_afr_open is set
and file is not open, then it needs repair. As of now I dont see any
problem with this algorithm but need to assess how complicated
it is to implement it. Because the more we do state maintenance,
the more the race conditions we will have to handle (that is a very
general statement though)
Will keep you guys informed regarding this.
Thanks
Krishna
>
> Anyways, you guys will have a much better idea of how feasible this
> actually is.
>
> --
>
> -Kevan Benson
> -A-1 Networks
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
