Hans Reiser <reiser@namesys.com> writes:
> This "feature" of not guaranteeing that a write that is in progress when the
> machine crashes will
>
> not write garbage, has been present in most Unix filesystems for about 25 years
> of Unix history.
A write in progress causing garabage when the power is lost is a
driver, and drive thing.
stock unix behavior is that it delays writes for up to 30 seconds,
which in case of a crash could mean you have old data on disk. Not
wrong data. This is helped because in stock unix filesystems blocks
are rarely reallocated or moved. In reiserfs with the btree at least
some kinds of data are moved all over the disk.
I want to suspect a btree problem on the block jumping around (it's
a good canidate). But unless you have messed up metadata journalling
btree writes are journaled. The reason I am suspecting the btree is
that most source code files are small so probably don't have complete
filesystem blocks of their own.
> It
>
> is not that we are deviant on this, it is that a tradeoff is made, and for most
> but not all users it
>
> is a good one to make.
If you can give me an explanation of what would cause the described
behavior of small files swapping their contents I would believe I
would feel more secure than just a reflex ``we don't garantee all of the
data written before power failure''.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:34 EST