Re: question about BIO/request ordering / barriers
From: Christophe Saout (christophe_at_saout.de)
Date: 12/31/03
- Previous message: John Bradford: "Re: i18n for kernel 2.7.x?"
- In reply to: Jens Axboe: "Re: question about BIO/request ordering / barriers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Jens Axboe <axboe@suse.de> 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/
- Previous message: John Bradford: "Re: i18n for kernel 2.7.x?"
- In reply to: Jens Axboe: "Re: question about BIO/request ordering / barriers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
