public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Christophe Saout <christophe@saout.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: question about BIO/request ordering / barriers
Date: Wed, 31 Dec 2003 16:56:07 +0100	[thread overview]
Message-ID: <20031231155607.GA5523@suse.de> (raw)
In-Reply-To: <1072879267.22227.10.camel@leto.cs.pocnet.net>

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.

> 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...

-- 
Jens Axboe


  reply	other threads:[~2003-12-31 15:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-31 14:01 question about BIO/request ordering / barriers Christophe Saout
2003-12-31 15:56 ` Jens Axboe [this message]
2003-12-31 16:08   ` Christophe Saout
2004-01-02 10:44     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031231155607.GA5523@suse.de \
    --to=axboe@suse.de \
    --cc=christophe@saout.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox