lkml.org 
[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: The INN/mmap bug
    Date
    Alexander Viro wrote:
    >
    > On Tue, 19 Sep 2000, Daniel Phillips wrote:
    >
    > > The more I think about it the less clear and ambiguous I find it.
    > > When you add the dirty bit into the pot you get:
    > >
    > > Mapped, Uptodate, Dirty: not possible
    >
    > Sure, it is possible - that's how the write happens
    >
    > > !Mapped, Uptodate, Dirty: not possible
    > > Mapped, !Uptodate, Dirty: pending write
    >
    > s/pending write/obvious bug/, damnit. Daniel, just think for a second: we
    > have the buffer read to be picked by bdflush and written to disk, while
    > the _contents_ _is_ _not_ _uptodate_. Just what can you expect when write
    > succeeds? Junk on disk, right? You know, GIGO queue - garbage in, garbage
    > out...
    >
    > > !Mapped, !Uptodate, Dirty: pending map and write
    >
    > Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these
    > reports?

    It wasn't a conceptual error, it was a typo: here's the corrected
    table with the wrongly tagged states you noticed
    interchanged:

    Mapped, Uptodate, Dirty: pending write
    !Mapped, Uptodate, Dirty: not possible
    Mapped, !Uptodate, Dirty: not possible
    !Mapped, !Uptodate, Dirty: pending map and write
    Mapped, Uptodate, !Dirty: regular block
    !Mapped, Uptodate, !Dirty: hole of zeroes
    Mapped, !Uptodate, !Dirty: unread
    !Mapped, !Uptodate, !Dirty: pending map

    > Sure, the dirty bit is not orthogonal to the rest. You don't need to do
    > any complex analysis - it's as simple as
    > * if I don't know _where_ to write the data - I'ld better not feed
    > the request to ll_rw_block(), or it may get PO'd
    > * if I know that data is junk - I don't want it hitting the disk.
    >
    > Dirty bit == request fed into the funnel and can be on disk any moment now.
    > Locked == already in IO subsystem.
    >
    > That's it - completely independent from the rest, except that you don't
    > want the whole write mechanism applied to non-uptodate or non-mapped
    > pieces.

    Right, two obvious bugs, which is the same thing as saying two uneeded
    states. Now, I'm just trying to be tidy and fit this all into a nice
    regular model that I can represent with state transition diagrams. I
    don't know for sure why it's good to do that, but it seems good. I
    like to imagine that if I could just get them all down on paper in a
    regular form some possible optimizations would just jump right out at
    me. Mind you, this is not necessary for the filesystem work I'm
    doing, this is more like a side interest. I get along just fine with
    the existing mechanism.

    > Think about IO as a memory bus - cache controller deals with writing the
    > cache line to RAM, but you don't want it to try that on lines that don't
    > have PA already calculated or have invalid contents. "mark dirty" == point
    > the write-behind mechanism to it and let it decide when the thing must be
    > written.

    I'd also like it to be able to decide on its own when to map the
    block. If I'm fully replacing the contents of a buffer on a page I
    would like to be able to just mark the buffer dirty without mapping it
    and let bdflush map it later. Right now it doesn't work because
    bdflush tries to feed a null block to ll_rw_block, but a small change
    would fix that: the flush daemon just has to notice the buffer is on a
    page, then it can call get_block to map it. Does this accomplish
    anything useful? I *think* so but I'm not sure. It seems to me that
    if you handled this properly you could have, for example, a temporary
    file written, read back and deleted, all without ever touching the
    disk, or even going into get_block to check for mappings, let alone
    fussing around with the allocation bitmaps.

    I'm also trying to determine if a 'don't know' mapping state would be
    useful for optimizing certain I/O paths.

    > Think how to make the cache indexed by virtual address (not by
    > physical, as in case of x86) work correctly. That's what pagecache is -
    > software MMU with cache-by-VA architecture.

    --
    Daniel
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:7.200 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site