[OpenAFS-devel] Re: The ihandle sync thing

[Andrew Deason]

On Thu, 28 Mar 2013 08:04:45 -0400
chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> On Wed, 27 Mar 2013 17:19:07 -0400
> Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:
> 
> > Just because ext3 (in ordered mode) does something doesn't mean it's
> > correct or something you should count on. If you don't
> > fsync/fdatasync, there is no guarantee your data is on the media or
> > ever will be on the media.

Doesn't pdflush guarantee this? That something doesn't stay around in
memory forever.

> > P.S. I am aware that ih_reallyclose() calls OS_SYNC(), but it's not
> > very useful.  ih_reallyclose() is not called under normal
> > circumstances except when deleting files or detaching volumes (on
> > DAFS or shutdown)

Well, or on some volume operations. I thought the motivation for getting
the synchronous syncs out of the way was primarily volume operations
(i.e. restores), since that's where you have a ton of (poorly-placed)
syncs. For those, with that proposed patch we'd sync at the end of the
volume transaction. Syncing before the end of the volume transaction
doesn't seem useful, since if you have an unclean shutdown in the middle
of such an op, the volume is inconsistent anyway (even if we've been
synchronously syncing the whole time), and you'd need to re-release or
whatever.

But of course that's not true for fileserver writes. Those seem more
feasible to make synchronous, since they happen less quickly and already
depend on some synchronous delay since we need to wait for the net.

> Perhaps standard fileservers should have a syncing thread by default
> (since they will never close a volume) and DAFS should not have a
> syncing thread.  It would be nice to have a config file per partition
> to specify this behavior though.

Like other filesystems &c, we could have 3 options so the user has the
illusion of choice without usually understanding what any of them
actually mean: sync, delayed sync, and no sync. All 3 of
those are still easy to do with the codebase, since all are doable via
the FDH_SYNC abstraction already used everywhere. Even though I don't
agree with some of the possible behavior with those, obviously, having
it runtime configurable would maybe mean we wouldn't need to keep
arguing about patches over and over again. (Instead we'd argue about
what options we tell people to use :)

Or we could spend time on putting the syncs in places that actually make
sense and guarantee consistency, but I'm not holding my breath for
_that_.

-- 
Andrew Deason
adeason@sinenomine.net