In the last episode (Oct 20), Alexander Leidinger said: > Zitat von Dan Nelson <dnelson_at_allantgroup.com>: > > Journalled filesystems may guarantee that the filesystem will be > > consistent to a particular point in time, so if your editor updates > > (for example) rc.conf by creating a new copy named rc.conf.new, > > deleting rc.conf, then renaming the copy to rc.conf, you are > > guaranteed that either rc.conf or rc.conf.new will be in the > > filessytem after a crash. With softupdates, you may lose both > > files. I don't know if current journalled fses actually journal > > all writes like this (as opposed to just journalling what the OS > > decides to flush out of its cache), but they are much less likely > > to lose files the way softupdates can. > > Sorry, this isn't true. Renaming a directory entry is an atomar > operation. Not only "man 2 rename" tells you about it, the > softupdates algorithm guarantees this too. If you move/rename an > entry into another directory, you may have both entries with the same > content, but you won't loose both. Yes, the rename itself is an atomic operation, but that doesn't help you if SU has commited the "delete rc.conf" step but has not yet committed the "write data for rc.conf.new" step. SU doesn't guarantee that its updates will be done in chronological order, just that at no point will the filesystem be inconsistent. The best solution is to fsync rc.conf.new before unlinking rc.conf to guarantee that it has been committed to disk. Note that /usr/bin/install has the same issues (and forcing a sync in there would really slow it down). I've lost so many files due to this that I run with kern.{meta,dir,file}delay set to {5,6,7} to make the window as small as possible while still giving me good performance. -- Dan Nelson dnelson_at_allantgroup.comReceived on Wed Oct 20 2004 - 15:09:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC