On Wed, 27 Mar 2013 17:19:07 -0400 Chaskiel Grundman <c...@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. _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
