lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: reiser4 plugins
    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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-06-28 01:14    [W:5.186 / U:0.668 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site