Read-only ReiserFS support for FreeBSD 5.x
Alexander Leidinger
Alexander at Leidinger.net
Thu Oct 21 06:02:27 PDT 2004
Zitat von Dan Nelson <dnelson at allantgroup.com>:
> 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
SU operates on the meta-data, if you need synchronous semantics for your
data-write operations, you have to change the mode of operation at mount
time. The same applies to journalling filesystems which don't operate in
synchronous mode for the user-data part of the filesystem (I don't know
how reiserfs handles this).
> 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
Yes, and every application which relies on such semantics but doesn't
fsync's the file(s) is broken (AFAIK some MTA's behave like this, and some
do the right thing).
/usr/bin/install can't know if a particular install needs such strict
constraints, so it's not supposed to fsync on it's own. If the installation
of a set of files fails (power failure or whatever), the entire installation
has to be repeated to make sure everything is ok. If you have a case where
you absolutely need to have such a semantic, you can do a sync on your own
("expensive" solution), or add a switch to install which tells it to fsync
(I'm sure someone is wiling to commit such a patch).
> (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.
I suggest to switch to better hardware if you experience a lot of such
failures (or teach the programs to do the right thing or configure the
filesystems to operate in sync mode)...
Bye,
Alexander.
--
http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137
A closed mouth gathers no foot.
More information about the freebsd-current
mailing list