On Thu, 28 Mar 2013 08:04:45 -0400 chas williams - CONTRACTOR <c...@cmf.nrl.navy.mil> wrote:
> On Wed, 27 Mar 2013 17:19:07 -0400 > Chaskiel Grundman <c...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
