Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: question about BIO/request ordering / barriers | From | Christophe Saout <> | Date | Wed, 31 Dec 2003 17:08:09 +0100 |
| |
Am Mi, den 31.12.2003 schrieb Jens Axboe um 16:56:
[Sorry for quoting the whole thing again, but I think the DM developers might know about the issue too]
> On Wed, Dec 31 2003, Christophe Saout wrote: > > Hi! > > > > I'm just digging through the device-mapper code and a question came up: > > > > Are "intermediate block device drivers" (like device-mapper) allowed to > > reorder BIOs? > > > > I'm not talking about BIOs submitted from different threads at the same > > time but BIOs submitted from the same thread sequentially, especially > > writes. > > > > That would mean that BIOs might be reordered around barriers which would > > break potential users. > > That would not be a good idea. Reordering around a barrier is forbidden, > you may reorder as you please otherwise. Consider yourself the io > scheduler, that is essentially the function you are performing. The io > scheduler will honor the barrier as well. > > > At the moment I suppose this shouldn't be an issue because I didn't find > > a single user in the whole kernel that actually submits BIOs with > > BIO_RW_BARRIER set via submit_bio/generic_make_request (journaling > > filesystems are simply waiting until all writes are finished before > > continueing, right?). > > Right, there are some missing bits still.
Ah, ok. So things are probably going to break in the future if they aren't fixed now. That's what I wanted do know.
> > There are same cases (in device-mapper) where > > > > a) writes get get suspended and queued for later submission where it is > > not ensured that those writes are submitted before any other writes that > > could possibly occur after the device gets resumed (generic dm code) > > b) a stack (instead of a fifo) is used to queue requests and submit them > > later (not yet included code) > > c) writes can get queued but reads are directly passed through > > (snapshotting code too) > > > > Also, if DM recevices a barrier shouldn't this barrier be somehow sent > > to all real devices instead of the one that the request is actually sent > > to? > > Yes, the driver must take whatever precautions necessary...
Ok, thanks. Let's see what can be done about that.
Is it possible to create empty BIOs that just act as barrier?
Because I think when device-mapper encounters a BIO with BIO_RW_BARRIER set it then should also create barriers for the other devices.
- 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/
| ![\](/images/icornerr.gif) |