On Fri, 29 Mar 2013 16:07:23 -0500 Andrew Deason <[email protected]> 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
