Re: Read-only ReiserFS support for FreeBSD 5.x

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.com