lkml.org 
[lkml]   [2005]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: I request inclusion of reiser4 in the mainline kernel
    Theodore Ts'o wrote:

    >
    > Another interesting refinement would be to analyze the resulting
    > filesystem after it has been repaired to determine how much data could
    > be salvaged by the fsck program.

    We use reiserfs3 to store data and have had very good luck in getting
    data off of real world, hard disk failures. In our case, we have a
    digital signature which is used to compare validate the content of the
    files after recovery so we have an extra comfort level with the results
    of a repaired file system...

    Working on getting fsck to run reliably and quickly on large file
    systems (any type of file system) is certainly a big item on our wish
    list. With relatively small file system (320GB) we can spend hours
    trying to recover.

    >
    > There is a very interesting paper that I coincidentally just came
    > across today that talks about making filesystems robust against
    > various different forms of failures of modern disk systems. It is
    > going to be presented at the upcoming 2005 SOSP conference.
    >
    > http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
    >
    > It's definitely worth a read. A few comments about it; first of all,
    > I know nothing about this modified "iron ext3" (ixt3) discussed in the
    > paper aside from what's the paper itself. It would be interesting to
    > see what they have done with it. Secondly, I _think_ sct has already
    > fixed the problems discussed in the paper with respect to inadequate
    > write squelching after an I/O failure writing to the ext3 journal, but
    > we need to chat with the paper's authors to confirm that, and if there
    > still is a problem, obviously we need to fix it. Third of all, I'll
    > note that the paper does takes an approving note of the fact that
    > Reiserfs (v3) always panic's when it detects a write fault, so for
    > those folks in the Reiser team who might have a persecution complex,
    > relax, the whole world isn't out to get you. :-)
    >
    > - Ted

    We have been sponsors of this work at Wisconsin - a good group with
    interesting results.

    As an earlier thread on lkml showed this summer, we still have a long
    way to go to getting consistent error semantics in face of media
    failures between the various file systems. I am not sure that we even
    have consensus on what that default behavior should be between
    developers, so image how difficult life is for application writers who
    want to try to ride through or write automated "HA" recovery scripts for
    systems with large numbers of occasionally flaky IO devices ;-)

    Ric




    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-09-21 02:36    [W:4.276 / U:0.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site