[lkml]   [2006]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: the " 'official' point of view" expressed by regarding reiser4 inclusion
    On Tue, 01 Aug 2006, David Masover wrote:

    > >RAID deals with the case where a device fails. RAID 1 with 2 disks can
    > >in theory detect an internal inconsistency but cannot fix it.
    > Still, if it does that, that should be enough. The scary part wasn't
    > that there's an internal inconsistency, but that you wouldn't know.

    You won't usually know, unless you run a consistency check: RAID-1 will
    only read from one of the two drives for speed - except if you make the
    system check consistency as it goes, which would imply waiting for both
    disks at the same time. And in that case, you'd better look for drives
    that allow to synchronize their platter staples in order to avoid the
    read access penalty that waiting for two drives entails.

    > And it can fix it if you can figure out which disk went.

    If it's decent and detects a bad block, it'll log it and rewrite it with
    data from the mirror and let the drive do the remapping through ARWE.

    > >Depending how far you propogate it. Someone people working with huge
    > >data sets already write and check user level CRC values for this reason
    > >(in fact bitkeeper does it for one example). It should be relatively
    > >cheap to get much of that benefit without doing application to
    > >application just as TCP gets most of its benefit without going app to
    > >app.
    > And yet, if you can do that, I'd suspect you can, should, must do it at
    > a lower level than the FS. Again, FS robustness is good, but if the
    > disk itself is going, what good is having your directory (mostly) intact
    > if the files themselves have random corruptions?

    Berkeley DB can, since version 4.1 (IIRC), write checksums (newer
    versions document this as SHA1) on its database pages, to detect
    corruptions and writes that were supposed to be atomic but failed
    (because you cannot write 4K or 16K atomically on a disk drive).

    Matthias Andree
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-03 16:01    [W:0.035 / U:160.320 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site