On 17 Jun 2004, Timothy Miller wrote:
> Petter Larsen wrote:
>
>> Data integrity is much more important for us than speed.
>
> You might want to consider ReiserFS or one of the others which were
> designed with journaling in mind. And I hope you're using RAID1 or
> RAID5.
I must admit, that isn't quite the response that I would have expected
for those requirements. :)
ReiserFS, XFS and (presumably) JFS all have considerably better
performance than ext3, for most tasks, because they were indeed designed
with journaling in mind.
OTOH, ReiserFS had an extremely long period of instability, and was
build by a group who felt that a working fsck was something you put
together after you got the filesystem working.
This, combined with the occasional "ReiserFS 3 ate my data" reports and
the reluctance of the developers to adapt to the 4K kernel stacks in
2.6.recent, would leave me hesitant to recommend it as "more
trustworthy" than ext3.
XFS, with the "null out data on recovery" mode, is less reliable than
ext3, full stop. It routinely destroys data in real world situations, a
secure, but irritating, choice.
ext3 remains the only journaling filesystem that I would, personally,
put any great degree of faith in, since it is still developed in a
cautious and safe fashion, and has a focus on getting the tools to
verify correctness in place before enabling kernel-side features.
Obviously, your millage may vary on these topics, as presumably have
your experiences.
Regards,
Daniel
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it.
-- Stephen Leacock
Daniel Pittman <[email protected]> said on Thu, 17 Jun 2004 10:51:54 +1000:
> XFS, with the "null out data on recovery" mode, is less reliable than
> ext3, full stop. It routinely destroys data in real world situations, a
> secure, but irritating, choice.
And please tell me -- the point of journalling is to reduce fsck times
upon failure - particularly important if you have 14TB of raid (yes,
we had to fsck after a recent downtime, and it had been > 180 days -
took half the day). What is the point of journalling if you have to
compare and restore against backup everytime the power fails? This is
slower than a mere fsckage.
FYI, I think jfs has the same behaviour as xfs - I do notice a
distinct lack of usage of a /lost+found, which has been important to
me in the past.
> ext3 remains the only journaling filesystem that I would, personally,
> put any great degree of faith in, since it is still developed in a
> cautious and safe fashion, and has a focus on getting the tools to
> verify correctness in place before enabling kernel-side features.
>
>
> Obviously, your millage may vary on these topics, as presumably have
> your experiences.
Sounds about right :)
Next time I reformat/get a new drive, I'll be going back to ext3 -
never caused any problems for me.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Single White Stick-Figure, L12, enjoys long walks by the shore,
cooking up a nice menudo, and bashing small animals with sticks. My
meat sword is enormous. Seeks female Accordian Thief for relationship
and buffs. -- Riff @ some game forum
Daniel Pittman wrote:
>OTOH, ReiserFS had an extremely long period of instability,
>
we were stable before ext3 was...
>and was
>build by a group who felt that a working fsck was something you put
>together after you got the filesystem working.
>
>
Well, if you have a total of two guys working on a filesystem, and
plenty not working yet in the filesystem, why the hell would you start
to work on fsck before the main body of code is working and performing
well enough that anybody would want to use it? Surely my task ordering
was correct for a two man team.
With Reiser4 we had funding for an fsck guy, and as a result fsck is
working at ship. With V3, we had no funding at all until it started to
work.
>This, combined with the occasional "ReiserFS 3 ate my data" reports and
>
>
like ext2/ext3, we are now able to say that almost all such reports are
hardware (for V3 not V4, V4 gained some bugs when we ported to -mm and
its radix trees, and is still not shipped as a result).
>the reluctance of the developers to adapt to the 4K kernel stacks in
>2.6.recent,
>
do you use them? I don't know real users who do, or else I would be
quicker to care.
On the one hand, you complain about how we were unstable, and on the
other hand you complain about how we aren't willing to destabilize the
code to add new features to what is no longer the development branch.
Seems pretty inconsistent logically to me.
On Wed, Jun 16, 2004 at 10:35:50PM -0700, Hans Reiser wrote:
> >the reluctance of the developers to adapt to the 4K kernel stacks in
> >2.6.recent,
> >
> do you use them? I don't know real users who do, or else I would be
> quicker to care.
The Fedora Core 2 kernel (and what will be RHEL4) is currently
using 4K stacks. This makes up quite a large userbase.
> On the one hand, you complain about how we were unstable, and on the
> other hand you complain about how we aren't willing to destabilize the
> code to add new features to what is no longer the development branch.
> Seems pretty inconsistent logically to me.
If you really are reluctant it fix it, there's always the option of
marking CONFIG_REISER4 as dependant on CONFIG_BROKEN if CONFIG_4KSTACKS
is selected.
Dave
Dave Jones wrote:
>On Wed, Jun 16, 2004 at 10:35:50PM -0700, Hans Reiser wrote:
>
> > >the reluctance of the developers to adapt to the 4K kernel stacks in
> > >2.6.recent,
> > >
> > do you use them? I don't know real users who do, or else I would be
> > quicker to care.
>
>The Fedora Core 2 kernel (and what will be RHEL4) is currently
>using 4K stacks. This makes up quite a large userbase.
>
>
Sigh. I guess we have to support it then.
Chris, are you up to doing it?
> > On the one hand, you complain about how we were unstable, and on the
> > other hand you complain about how we aren't willing to destabilize the
> > code to add new features to what is no longer the development branch.
> > Seems pretty inconsistent logically to me.
>
>If you really are reluctant it fix it, there's always the option of
>marking CONFIG_REISER4 as dependant on CONFIG_BROKEN if CONFIG_4KSTACKS
>is selected.
>
> Dave
>
>
>
>
>