Which journaling filesystem is most robust?

[glenn at vtecus.com (Glenn Burkhardt)]

"Keller, Tim" <Tim.Keller at stratus.com> wrote:
> I've been using ReiserFS in production for over a year without a problem.
> This machines got both Samba and NFS hanging off of it.  I'm also not sure
> how up to date that info about the slow response was?

There are notes on a number of mailing lists, some posted just days ago:

e.g.,

List:     reiserfs
Subject:  [reiserfs-list] Reiserfs performance with  knfsd
From:     Herman Knief <herman at knief.net>
Date:     2001-11-09 18:30:13

Why is it that Reiserfs performance is so... well, *crappy* when used on
an nfs server?

I have used numerous kernels... 2.2.19, 2.4.7, 2.4.10 (generic and SuSE
built.)  I have compared ext2, ext, Reiserfs and jfs.  I love the speed of
reiser for local file system usage, but when coupled with knfsd it seems
to suffer horribly.

List:     reiserfs
Subject:  Re: [reiserfs-list] Re: knfsd stalls on reiserfs
From:     Dave Mason <dmason at sarg.ryerson.ca>
Date:     2001-11-05 12:43:34
[Download message RAW]

>>>>> On Sun, 04 Nov 2001 10:15:12 -0800, Herman Knief <herman at knief.net> said:

> I've run into similar issues with the system seeming to stall, but
> mine were related more to bdflush and kreiserfsd competing for
> resources.  Some system tuning helped that out quite a bit.

> Can you start top, then start to hammer the nfs... see what top is
> showing when it seems to stall.

> My bet is kswapd, bdflush, kupdated, along with kreiserfsd are at
> the top when it misbehaves, and the nfsd's will drop off the chart.
> Let me know if this is accurate.

You're absolutely correct!

The system runs along fine for a long time.  Load average around 1,
each CPU about 30-40% active, nfsd using all of the time.  Then all of
the nfsd processes stop, kupdated goes nuts, load average goes to 2.2
within 10 seconds, makes it over 7 over the following 70 seconds, then
kupdated goes away, nfsd comes back, kreiserfsd blips, and the load
average starts dropping back to normal.  That snapshot from the log is
at the end of this message.  I looked through the whole log and memory
looks the same throughout.