linux user group brescia

Alfredo Quartini wrote:
> Hei ragazzi,
> 
> non fatemi rimpiangere Sun + Solaris + UFS.

Vuoi che ti racconti qualche storia dell'orrore su UDS? :)

> Ho ancora qualche giorno di tempo per decidere; la cosa si sta facendo
> interessante.

Mando questa mail riassuntiva di D. Robbins (non proprio il capo dei 
fessi), la situazione si ingarbuglia sempre di più...:)



OK, I think it's good if I summarize my experiences with the various
filesystems:

ext3 has been a solid filesystem for quite a long time. It also runs by
default in "ordered" data/metadata mode, which means that the "data not
flushed to disk" problem is nearly eliminated. It also offers a full
data journaling mode to provide the ultimate in data protection. While
ext3 has been pretty much solid from its inception, it's still no
replacement for regular backups.

Now, for ReiserFS. ReiserFS has had tons of problems in the past, up
until 2.4.18. Many of these issues were not the fault of the ReiserFS
developers, but were an unfortunate result of how the kernel is
developed. Example: ReiserFS developers submit a patch to Linus. Linus
applies their patch to a Linux kernel along with a new VFS layer that
the ReiserFS developers have never seen before. Linus releases kernel
without giving the ReiserFS developers the chance to test their patch
with the new VFS code. As one might imagine, this tends to allow for
buggy ReiserFS/VFS interactions to hit the public. To drive this point
home, SuSE has never had a flaky ReiserFS implementation because they
*pay* the ReiserFS developers to QA test their SuSE kernel before it is
released to the public.

 From 2.4.18 onwards, ReiserFS is very solid and very refined now that
the kernel (in particular the VFS code) has stabilized. Filesystem
corruption issues are gone. In fact, the ReiserFS dev team is receiving
so few bug reports that employees responsible with tracking bugs have
had to focus on other areas of ReiserFS development. However, many
people are still burned by ReiserFS and refuse to use it until it has
more of a track record. Personally, I am using ReiserFS exclusively on
my development box, even though I've lost gigabytes of data due to flaky
ReiserFS code in the past.  I've been using ReiserFS for months, for
*insane* things (the equivalent of maybe 50 stage3 builds on a single
filesystem) with no problems or corruption or anything. My system has
locked up when I've tried new experimental kernels and other weird
things, and I've had no data loss issues. We have also started using
ReiserFS again on chiba (gentoo.org) server and have had no issues. We
store our CVS repository on it.

Comparing XFS and ReiserFS, XFS has more "data loss on power off"
issues. The reason appears to be that XFS still has certain areas of its
code that require synchronous metadata updates. Synchronous metadata
updates cause all pending metadata updates to be flushed to disk. This
behavior is what made deleting files on XFS so painfully slow in XFS
1.0. With XFS 1.1, many internal synchronous metadata requirements have
been eliminated, but there are still enough to trigger the "data loss on
power off" problem quite often, even almost *predictably* (like *all the
time, every time*) for certain patterns of IO operations.

So yes, if you ignore the details, neither XFS nor ReiserFS have ordered
data writes so they should both experience this problem with the same
frequency and severity. In reality, however, there are certain patterns
of IO operations that will cause this "data loss on power off" issue to
strike with frightening regularity on XFS. In contrast, ReiserFS's
out-of-order writing doesn't seem to be able to cause much if any
catastrophic damage even if you're trying to trigger the problem. That's
why I added the warning to the install docs.





-- 
Bauno - Eurydices, oro, properata retexite fata!
"A cynic is a man who, when he smells flowers, looks around for a coffin."
- H. L. Mencken