lkml.org 
[lkml]   [2002]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ide filters / 'ide dump' / 'bio dump'
    Jeff Garzik writes:
    > bert hubert wrote:
    >
    > ># biodump /dev/hda
    > >09:09:33.023 READ block 12345 [10 blocks]
    > >09:09:33.024 READ block 12355 [10 blocks]
    > >09:09:33.025 READ block 12365 [10 blocks]
    > >09:09:34.000 WRITE block 12345 [1 block]
    > >
    >
    >
    > Definitely an interesting idea... With this new stuff Linus talked
    > about in his proposal and what I'm thinking about, it shouldn't be too
    > hard to do.

    I wrote a basic version of that (reqlog) a couple of years ago (with
    the writing of the rw/block/size info inline in the kernel rather than
    via a nice separate filter). The use I put it to was for migrating
    block devices live (i.e. while being read/written) without having to
    quiesce the readers/writers except for a few seconds at the end. The
    idea is that you set up (as an ordinary userland process) a bitmap
    in memory for all the blocks on the device. You start with them all
    marked dirty. You then do two loops concurrently (select() or threads):
    while (1) {
    read next block/size touched
    mark corresponding bits dirty in bitmap
    }
    and
    while (1) {
    while (find_next_dirty_bit_in_bitmap()) {
    mark bit clean
    read corresponding block from device
    send blocknumber, blockdata to remote peer
    }
    go back to start of bitmap
    }

    The remote peer is a daemon which just reads the (blocknumber,data)
    pairs and writes the data to the snapshot-to-be device at its end.
    Eventually, the bitmap gets mostly clean and the migrating process
    has "caught up" and is just siphoning newly dirtied data off to the
    remote end in real time. At that point, you quiesce the writing
    applications nicely for a few seconds (database, serving daemons or
    whatever is writing to the device) and let the migrator clean the
    bitmap fully (the last few blocks) and at that point you have a
    point-in-time safe snapshot at the remote end.

    With filters available (presumably as modules) for the bio stuff,
    this will become possible without having to patch the kernel (I think
    I submitted the reqlog and bufflink patches for inclusion but
    didn't care enough to keep trying).

    See
    http://www.clueful.co.uk/mbeattie/linux-kernel.html#reqlog
    and bmigrate and bufflink on the same page for the "old" way. It's
    basic stuff and new APIs mean a rewrite will be much easier but I
    thought you may be interested in another application of such logging.


    --Malcolm

    --
    Malcolm Beattie <mbeattie@clueful.co.uk>
    Linux Technical Consultant
    IBM EMEA Enterprise Server Group...
    ...from home, speaking only for myself
    -
    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-03-22 13:24    [W:4.812 / U:0.660 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site