Hi! On Sat, 2010-03-06 at 21:35:04 +1100, Russell Coker wrote: > On Sat, 6 Mar 2010, Guillem Jover <[email protected]> wrote: > > This guarantees the file contents will be there in case of abrupt > > program termination (due to crashes for example, or user intervention). > > This also guarantees the atomicity of rename(2) calls. > > This description is incorrect.
Well I'd say pretty unfortunate or inaccurate more than incorrect. But, yeah I meant to amend it before the push but it seems I forgot. :/ Thanks for the notice, though! > fsync() has no bearing on what will happen if the program crashes. If a > program crashes immediately after a write() system call has succeeded then > the kernel will take care of flushing the cache to disk afterwards. > fsync() is used specifically to deal with the case of abrupt OS termination > due to a kernel crash or hardware failure. The only user intervention which > is relevant is that which involves the reset button, the power switch, > or "shutdown -nf". This is particularly difficult in the case of a cluster > where a "reboot -nf" or IPMI reboot is a rare but normal part of the > operation of the system. Right, with crash and user intervention I was specifically referring to those kind of cases, and program termination due to those external causes. In addition fsync() cannot “guarantee the contents will be there in case of abrupt ...”, it can only guarantee they will be there for the next operation that might get performed. Probably the worst commit message I've ever pushed. :) Anyway, not much that can be done now, as the commit log cannot be modified, and I'm not sure I can push a git note to a remote repo. Regardless, the bug should be mostly fixed now, as fsync()s are done on all extracted files, and on the database directories, the remaining part is fsync()ing dirty dirs from the file system, but I'll leave this for later. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
