[OpenAFS-devel] Re: The ihandle sync thing

[Andrew Deason]

On Fri, 29 Mar 2013 13:05:07 -0400
chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> I suspect it is the "usually" that upsets people attached to their
> data.  Perhaps it would not be too difficult to actually fix the
> fileserver correctly as suggested by Andrew.  Relying on the
> background threads to "synchronize" the filesystem metadata and the
> afs filesystem metadata does seem a bit perilous.

I didn't mean to say the fileserver behavior was broken. The common case
for FDH_SYNCs in the fileserver should be simple pwrite()/fsync()
sequences. The part that's "broken" is volume operations, especially
namei link table manipulation. (The fileserver maybe does a bit with
this for CoW, but I imagine those are not as much of a problem.) Fixing
_that_ is not a huge amount of work, but in my opinion out of the
question for 1.6.3.

For the fileserver, you either fsync() after a WriteData64, or you
don't; there's not much you can really do right or wrong there. If you
find the fsync() delays there unacceptable, then no behavior that gives
you consistency guarantees is going to make you happy. However, there
are some situations where people may want something like that. During
release-team discussions it was suggested that we may actually add a
runtime parameter for this, similar to what I mentioned before. This has
been submitted in <http://gerrit.openafs.org/#change,9694>, and my
understanding is that this may go in 1.6.3. (The 1.6 submission will
have the mentioned-but-invalid 'delayed' option, or whatever I called
it.)

If people could look at that and say if that makes them happy or not, it
would be helpful. My hope with something like that is that while various
parties may never agree what the 'right' option is, we can stop making
decisions on this by patching.

-- 
Andrew Deason
adeason@sinenomine.net