Re: reiser4 plugins

[Prakash Punnoor]

Steve Lord schrieb:

> I see no way short of hardware fixes of avoiding the general problem of
> a system failing in an ugly manner like this. Unless you write everything
> to disk twice (i.e. journal all data), you can still end up with a
> legitimate set of metadata, and the master copy of your employee
> database full of nasty little bits of corruption.

If I as a user may add my own little experience with different fs on my
computer, where I tend to use kernels or features that cause my machine to
(hard) lock up:

2.4.2x kernel and reiserfs (V3): This was the only one which really managed to
smoke my partition...

2.6.x-test-y till 2.6.x stable kernel and reiserfs (V3): I did a short
intermezzo with xfs but at that time it felt too slow to bear, so I gave
reiserfs another chance. And here it was very robust. No lock-up did serious
damage to the data. Only currently accessed files were partly overwritten with
@^@^@^ and so on...

After a year or so of heavy usage the formerly fast reiserfs partition became
more and more slow till I got sick of it. So I tried JFS and forced a hard
lock. Data was OK, but (probably error in gentoo scripts) fsck wasn't
automatically called (or failed, I don't remember) and I had to do it by hand,
which was a major annoyance - I thought then.

So I gave ext3 a try. Very robust, but at the same time slooow. I couldn't
bear it after some months. So I gave xfs another try. Yes, now it felt much
better. Still not that fast as reiserfs, IIRC, but better than the first time
I tried. I am still having xfs on / and it works pretty well, and is rather
robust against hard locks with about the same amount of data losing as
reiserfs. But what annoys me very much, is that I have to run xfs_repair by
hand and by booting from another partition. Even after a hard lock, the
partition mounts w/o problems and everything seems OK, but it only seems like
that. In fact after some hours/days of use, you'll notice oddities, like files
or directories which cannot be removed and things like that. After running
xfs_repair everything is back in order.

In between I gave an alpha (or rather several alphas) of reiser4 a try - but
not on /, just on /usr. Well, I wouldn't say it was extraordinary fast. In
fact it felt slower than reiserfs V3, but much more space efficient. And to my
surprise it was very robust as well. Hard-locks were no problem. Only annoying
then was, that unmounting regularly produced oops but later versions corrected
that. But nevertheless it didn't survive, as like V3, with time V4 became
slower and slower. In this case no year was needed, but just one month or
alike. So end of test...but in fact I'll give V4 another go in the near future.


All in all I can say that every fs I tested was able to not smoke all of my
data, even using an instable machine - but only ext3, reiser v3 and v4 were
non-annoying. But xfs is majorly annoying in that respect. I hope that new
versions will be able to keep consistency w/o having to run xfs_repair every
time after a lock-up...

But what I don't understand is, that sometimes even files, which were only
opened for reading, got overwritten with @^@^@ after a lock-up. I don't
understand the logics here, how this could happen.

Thx for your time,

Prakash

Attachment: signature.asc
Description: OpenPGP digital signature