[OpenAFS-devel] The ihandle sync thing

[chas williams - CONTRACTOR]

On Wed, 27 Mar 2013 17:19:07 -0400
Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:

> It seems that openafs 1.6.3 will remove the ihandle sync background
> thread that was put in when foreground syncs were removed many years back.
> 
> part of the commit message says:
> 
> "Additionally, journalling filesystems common on fileserver backends
> will typically ensure some consistency after a certain amount of time
> (by default, 5 seconds on ZFS and ext3+), so doing this sync ourselves
> is often redundant or even counterproductive."
> 
> 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.

Even that is not a guarantee that your data is going to be on the
media.  The device may have your data in its write cache.  Nothing in
life is certain, and I am not sure that the fileserver syncing thread is
making life more certain in most cases.

> I understand the current use of the ihandle cache for this is problematic,
> but that is not an excuse to never sync.
> 
> I will be sad if I have to patch foreground syncs back into my
> fileservers, but I will if I have to.
>
> 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)

I think the recommendation going forward is that people should use
DAFS.  Volumes that are attached during a catastrophic failure are
always going to be in some sort of limbo state (since Murphy's law will
require that the failure will happen in the middle of I/O).

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.