[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [Gluster-devel] proposals to afr
From: |
Krishna Srinivas |
Subject: |
Re: Fwd: [Gluster-devel] proposals to afr |
Date: |
Fri, 26 Oct 2007 01:10:05 +0530 |
On 10/26/07, Kevan Benson <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
- Re: Fwd: [Gluster-devel] proposals to afr, (continued)
- Re: Fwd: [Gluster-devel] proposals to afr, Kevan Benson, 2007/10/24
- Re: Fwd: [Gluster-devel] proposals to afr, Alexey Filin, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr, Alexey Filin, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr, Krishna Srinivas, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr, Chris Johnson, 2007/10/25
- Message not available
- Re: Fwd: [Gluster-devel] proposals to afr, Chris Johnson, 2007/10/25
- Re: [Gluster-devel] option client-volume-filename (was) Re: Fwd: [Gluster-devel] proposals to afr, Matt Paine, 2007/10/25
- Re: [Gluster-devel] option client-volume-filename (was) Re: Fwd: [Gluster-devel] proposals to afr, Chris Johnson, 2007/10/26
- Re: Fwd: [Gluster-devel] proposals to afr, Krishna Srinivas, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr, Kevan Benson, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr,
Krishna Srinivas <=
- Re: Fwd: [Gluster-devel] proposals to afr, Alexey Filin, 2007/10/26
- Re: Fwd: [Gluster-devel] proposals to afr, Alexey Filin, 2007/10/30
- Re: Fwd: [Gluster-devel] proposals to afr, Kevan Benson, 2007/10/25
- Re: Fwd: [Gluster-devel] proposals to afr, Alexey Filin, 2007/10/25