how to do asynchrounous I/O at the device level?

• Previous message: Dag-Erling Smorgrav: "Re: gcc bug? Openoffice port impossibel to compile on 4.8"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 29 May 2003 08:36:55 -0400 (EDT)
To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org

I'm not sure if this a question for fs or hackers, so I apologize if
you see this twice.

I'm writing a device driver for a "soft-mirrored" disk. The idea is
similar to ordinary disk mirroring, except that the focus is entirely
on higher performance instead of fault tolerance -- the secondary disk
need not be an exact duplicate of the first. (I have a method for
keeping track of which blocks on the secondary are actually in sync
with the primary, and which might contain stale data.)

What I want to do is an ordinary write to the primary disk and an
asynchronous write to the secondary, so that it is possible that the
calling process can continue on its way before the writes are actually
finished on the secondary.

I've implemented my scheme with synchronous mirror writes by hacking
up the CCD driver. (This wasn't a big deal, because CCD already
implements disk mirroring, but because I'm also futzing around with a
bunch of other stuff, the resulting code is structured a bit
differently.) Now I want to make the secondary writes asynchronous.

The challenge is that I need to make copies of whatever state the
device underneath CCD needs in order to do the I/Os. As soon as the
primary writes are finished, the file system is going to deallocate or
reuse the structures it passed down to CCD. I can't hack the file
system code to delay this, because I need to hide all this inside the
device driver.

I know I need to copy the buffer, and clone the buf struct. My
questions are:

1. How to properly clone the buf struct to make a "standalone" buf.

        Just bcopy'ing it will result in it being filled with pointers
        linking it to the rest of the buffer pool, which I suspect
        will lead to horrible problems later -- I'm pretty sure that I
        don't want the buffer manager to know about this buf, or this
        buf to believe it's part of the buffer pool.

2. Whether there's any other state that I need to preserve.

If this sort of thing has already been implemented somewhere, just
point me to it...

Thanks,
        -Dan

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

• Previous message: Dag-Erling Smorgrav: "Re: gcc bug? Openoffice port impossibel to compile on 4.8"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]