[lkml]   [2000]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Test12 ll_rw_block error.

    On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:

    > Hi,
    > On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
    > > On Thu, 14 Dec 2000, Linus Torvalds wrote:
    > >
    > > Just one: any fs that really cares about completion callback is very likely
    > > to be picky about the requests ordering. So sync_buffers() is very unlikely
    > > to be useful anyway.
    > >
    > > In that sense we really don't have anonymous buffers here. I seriously
    > > suspect that "unrealistic" assumption is not unrealistic at all. I'm
    > > not sufficiently familiar with XFS code to say for sure, but...
    > Right. ext3 and reiserfs just want to submit their own IOs when it
    > comes to the journal. (At least in ext3, already-journaled buffers
    > can be written back by the VM freely.) It's a matter of telling the
    > fs when that should start.
    > > What we really need is a way for VFS/VM to pass the pressure on filesystem.
    > > That's it. If fs wants unusual completions for requests - let it have its
    > > own queueing mechanism and submit these requests when it finds that convenient.
    > There is a very clean way of doing this with address spaces. It's
    > something I would like to see done properly for 2.5: eliminate all
    > knowledge of buffer_heads from the VM layer. It would be pretty
    > simple to remove page->buffers completely and replace it with a
    > page->private pointer, owned by whatever address_space controlled the
    > page. Instead of trying to unmap and flush buffers on the page
    > directly, these operations would become address_space operations.
    > We could still provide the standard try_to_free_buffers() and
    > unmap_underlying_metadata() functions to operate on the per-page
    > buffer_head lists, and existing filesystems would only have to point
    > their address_space "private metadata" operations at the generic
    > functions. However, a filesystem which had additional ordering
    > constraints could then intercept the flush or writeback calls from the
    > VM and decide on its own how best to honour the VM pressure.


    The ->flush() operation (which we've been discussing a bit) would be very
    useful now (mainly for XFS).

    At page_launder(), we can call ->flush() if the given page has it defined.
    Otherwise use try_to_free_buffers() as we do now for filesystems which
    dont care about the special flushing treatment.

    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 12:52    [W:0.021 / U:40.580 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site