lkml.org 
[lkml]   [2005]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux does not care for data integrity (was: Disk write cache)
    On Mon, 16 May 2005, Arjan van de Ven wrote:

    > > See the problem: "I assume", "IIRC selected...". There is no
    > > list of corroborated facts which systems work and which don't. I have
    > > made several attempts in compiling one, posting public calls for data
    > > here, no response.
    >
    > well what stops you from building that list yourself by doing the actual
    > work yourself?

    Two things.

    #1 it's the subsystem maintainer's responsibility to arrange for such
    information. I searched Documentation/* to no avail, see below.

    #2 That I would need to get acquainted with and understand several dozen
    subsystems, drivers and so on to be able to make a substantiated
    statement.

    Subsystem maintainers will usually know the shape their code is in and
    just need to state "not yet", "not planned", "not needed, different
    layer", "work in progress" or "working since kernel version 2.6.42".

    Takes a minute per maintainer, rather than wasting countless hours on
    working through foreign code only to forget all this after I know what I
    wanted to know. Sounds like an unreasonable expectation? Not to me. I
    had hoped, several times, that asking here would give the first dozen of
    answers as a starting point.

    It's not as though I could go forth and just take two weeks off a shelf
    and read all common block devices code...

    I still have insufficient information even for ext3 on traditional
    parallel ATA interfaces, so how do I start a list without information?

    $ cd linux-2.6/Documentation/
    $ find -iname '*barr*'
    ./arm/Sharp-LH/IOBarrier
    $ head -4 ../Makefile
    VERSION = 2
    PATCHLEVEL = 6
    SUBLEVEL = 11
    EXTRAVERSION = .9
    $

    Documentation/block/biodoc.txt has some information about how it could
    look like two years from now. filesystems/ext3 mentions it requires a
    barrier=1 mount option. No information what block interfaces support it.

    AIC7XXX was once reported to have it, experimentally, I don't know what
    has become of the code, and I don't have AIC7XXX here, too expensive.

    --
    Matthias Andree
    -
    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-05-16 16:52    [W:0.023 / U:61.912 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site