On Fri, 29 Mar 2013 13:05:07 -0400 chas williams - CONTRACTOR <[email protected]> wrote:
> I suspect it is the "usually" that upsets people attached to their > data. Perhaps it would not be too difficult to actually fix the > fileserver correctly as suggested by Andrew. Relying on the > background threads to "synchronize" the filesystem metadata and the > afs filesystem metadata does seem a bit perilous. 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. 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 release-team discussions it was suggested that we may actually add a runtime parameter for this, similar to what I mentioned before. This has been submitted in <http://gerrit.openafs.org/#change,9694>, and my understanding is that this may go in 1.6.3. (The 1.6 submission will have the mentioned-but-invalid 'delayed' option, or whatever I called it.) If people could look at that and say if that makes them happy or not, it would be helpful. My hope with something like that is that while various parties may never agree what the 'right' option is, we can stop making decisions on this by patching. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
