[OpenAFS-devel] Re: The ihandle sync thing
chas williams - CONTRACTOR
chas@cmf.nrl.navy.mil
Mon, 1 Apr 2013 08:06:22 -0400
On Fri, 29 Mar 2013 16:07:23 -0500
Andrew Deason <adeason@sinenomine.net> wrote:
> 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.
I was thinking that you might be talking about using fdatasync() in
places where it makes sense instead of doing fsync() for everything.
some filesystems are beginning to support a fdatasync() that is
separate from fsync().
> 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
My point is that this "sync after every write" behavior may not
actually be completely sufficient. apparently some filesystems and
operating systems may require a sync to the parent directory to put the
underlying filesystem metadata to disk for file creation and deletion.
The sync after every write gives a false sense of security given that
the underlying filesystem might lose track of your carefully synced
file because the directory data pointing to it was lost.