lkml.org 
[lkml]   [2003]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: question about BIO/request ordering / barriers
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.092 / U:0.004 seconds]
©2003-2011 Jasper Spaans. Advertise on this site