[lkml]   [1997]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to freeze 2.0.31 pre7 :(
       Date: 	Fri, 22 Aug 1997 13:05:19 -0400
    From: Bill Hawes <>

    Unfortunately this looks like a loop device too-many-dirty-buffers
    deadlock. In spite of the numerous kludges in the buffer code to
    attempt to circumvent such deadlocks, there appear to be cases that
    aren't covered.

    I would very much like to see a loop device that operated only
    synchronously, so that there were _never_ any dirty loop device

    Since this old issue is being brought up, I want to mention a few

    Back a few months ago I started a half assed project to redo the
    entire I/O subsystem, a lot of people joined in and things began to
    happen, but due to various things (some people becomming fathers,
    others becomming busy for other reasons) the plane never left the

    Part of our foundation of initial ideas included a global I/O
    labelling strategy. Linus wants to keep the name buffer_head, and I
    agree with most of the technical details he has mentioned. I just
    don't think we should keep the name if we're changing the behavior
    radically on one end.

    Here is sort of what we wanted things to look like (pay attention to
    architecture, not details):

    1) Anyone who needs to move data between memory and a block device
    is by definition an I/O client, they are responsible for:

    a) Determining where the buffers are in ram
    b) where it is on disk
    c) acquire exclusivity (wrt. SMP and traditional UP mutual
    exclusion issues)
    d) call into I/O request layer
    e) check for errors, unlock stuff

    2) I/O request layer solely performs the function of:

    a) Accepting calls in from clients, using the generic
    block device I/O tags, call them buffer_head or whatever,
    point remains the same
    b) Queue it
    c) Schedule to device driver
    d) Call back when done or error

    One of the major goals was to put all the locking of resources at the
    client level, they can see more of their picture than the I/O request
    manager can, it is in fact none of his buisness, the locking. I
    believed that this could partly help with the loop device overcommital
    and other problems.

    Second most important reason we wanted to rework things was so that we
    could allow for two important features block I/O in Linux needs badly:

    a) physio
    b) arbitrary ordering constraints for the I/O operations

    Also we wanted to add a more complete way for filesystems to enable a
    "sync it now like BSD, I don't care about performance and I don't
    believe that non-sync I/O won't lose data for me should the system go
    belly up and crash" mode. b) is for things such as logging
    filesystems where strict I/O ordering is a must. Ted T'ytso had plans
    to add such capabilities to ext2, but true I/O ordering is necessary
    for a correct implementation.

    A quick mention back to the swap or anonymous inode idea. Adding it
    would allow us to do "safe" swapping, this would also make a lot of
    people happy who are more concerned about stability than raw
    performance. And it can be done such that the "rest of us" don't get
    penalized performance wise, only those who want anon swap
    preallocation eat the cost.

    David "Sparc" Miller

     \ /
      Last update: 2005-03-22 13:40    [W:0.021 / U:18.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site