[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: patch: reiserfs for 2.3.49

    On Mon, 13 Mar 2000 16:19:39 +0100, Jamie Lokier
    <> said:

    > Alex Viro's concerns are not about whether reiserfs passes stress
    > tests. They're about subtle, and not to subtle deadlock, livelock and
    > race conditions, and long term maintainability.

    That's certainly part of it.

    For true production-quality robustness, there are a whole pile of things
    which need to be dealt with which aren't necessarily perfected just by
    getting stress tests running reliably. It might be useful to get a
    check-list of things which are easy to overlook. As a first attempt,
    I'd include:

    * Locking

    This has already been mentioned. 'Nuff said.

    * Fault handling

    The filesystem must respond cleanly to *all* out-of-memory failures
    and media EIO errors. The response to ENOMEM may be to spin
    waiting for memory, and EIO may take the filesystem offline, but in
    either case when control returns to user space the filesystem must
    be in a known state in which all resources used by that syscall are
    released and the filesystem can be unmounted.

    The bad_inode stuff is particularly useful for handling "I can't go
    any further!" EIO failures, and in the worst case, ENOMEM can always
    result in a panic: the admin can set a reboot-on-panic timeout so if
    things go unrecoverably wrong, we at least get an automatic clean
    boot out of it.

    * fsck.

    This is something Ted has been very good about: there is a
    comprehensive regression suite in e2fsprogs to test not only
    recovery from normal situations on the disk, but also to recover
    from all manner of corruptions which cannot occur in the normal
    running of the filesystem but which happen when memory goes bad,
    media fails, the user runs fsck on a mounted partition and then ^Cs
    it, or whatever. There should be no combination of on-disk
    conditions which should allow fsck to crash, even though some forms
    of corruption won't let you recover much of any value!

    * Scaling up

    Cache management and writeback policies need to be tested and proven
    on very, very big boxes.

    * Scaling down

    Cache management and writeback policies need to be tested and proven
    on very, very small boxes. :-)

    If you deadlock when running half a dozen filesystems on a 16MB box,
    something is wrong. I think we need extra VM infrastructure to deal
    reliably with this: both ext3 and reiserfs will be hurt by the need
    to build whole transactions before committing stuff to disk, as we
    may run out of memory mid-transaction while the rest of the
    transaction is still pinned.

    Just a few thoughts: it's probably useful to keep a checklist like this
    in mind as we bring new filesystems into the mainstream. Anything I've


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

     \ /
      Last update: 2005-03-22 13:57    [W:0.022 / U:3.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site