From: Eric Sandeen <sandeen@redhat.com>
To: device-mapper development <dm-devel@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Jens Axboe <jens.axboe@oracle.com>, Andi Kleen <ak@suse.de>,
"MASON,CHRISTOPHER" <CHRIS.MASON@oracle.com>
Subject: Barriers still not passing on simple dm devices...
Date: Mon, 23 Mar 2009 14:04:28 -0500 [thread overview]
Message-ID: <49C7DD3C.2020401@redhat.com> (raw)
I've noticed that on 2.6.29-rcX, with Andi's patch
(ab4c1424882be9cd70b89abf2b484add355712fa, dm: support barriers on
simple devices) barriers are still getting rejected on these simple devices.
The problem is in __generic_make_request():
if (bio_barrier(bio) && bio_has_data(bio) &&
(q->next_ordered == QUEUE_ORDERED_NONE)) {
err = -EOPNOTSUPP;
goto end_io;
}
and dm isn't flagging its queue as supporting ordered writes, so it's
rejected here.
Doing something like this:
+ if (t->barriers_supported)
+ blk_queue_ordered(q, QUEUE_ORDERED_DRAIN, NULL);
somewhere in dm (I stuck it in dm_table_set_restrictions() - almost
certainly the wrong thing to do) did get my dm-linear device to mount
with xfs, w/o xfs complaining that its mount-time barrier tests failed.
So what's the right way around this? What should dm (or md for that
matter) advertise on their queues about ordered-ness? Should there be
some sort of "QUEUE_ORDERED_PASSTHROUGH" or something to say "this level
doesn't care, ask the next level" or somesuch? Or should it inherit the
flag from the next level down? Ideas?
Thanks,
-Eric
next reply other threads:[~2009-03-23 19:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-23 19:04 Eric Sandeen [this message]
2009-03-23 19:10 ` Barriers still not passing on simple dm devices Eric Sandeen
2009-03-24 14:02 ` [dm-devel] " Mikulas Patocka
2009-03-24 14:05 ` Jens Axboe
2009-03-24 14:26 ` Mikulas Patocka
2009-03-24 14:30 ` Jens Axboe
2009-03-24 14:45 ` Mikulas Patocka
2009-03-24 15:05 ` Jens Axboe
2009-03-25 15:15 ` Mikulas Patocka
2009-03-25 15:27 ` Jens Axboe
2009-03-25 22:39 ` Mikulas Patocka
2009-03-26 8:42 ` Jens Axboe
2009-03-31 3:39 ` Mikulas Patocka
2009-03-31 10:49 ` Jens Axboe
2009-04-02 23:40 ` Mikulas Patocka
2009-04-03 8:11 ` Jens Axboe
2009-04-04 15:20 ` Ric Wheeler
2009-04-05 1:28 ` Theodore Tso
2009-04-05 11:54 ` Ric Wheeler
2009-04-06 1:14 ` Lee Revell
2009-04-06 1:24 ` Ric Wheeler
2009-04-08 12:44 ` Mikulas Patocka
2009-04-08 15:16 ` Henrique de Moraes Holschuh
2009-04-09 4:22 ` Eric Sandeen
2009-04-08 12:36 ` Mikulas Patocka
2009-04-08 12:54 ` Mikulas Patocka
2009-04-09 10:48 ` Ric Wheeler
2009-04-08 13:37 ` Mikulas Patocka
2009-04-08 14:06 ` Jens Axboe
2009-04-08 23:44 ` Dave Chinner
2009-04-09 1:27 ` Chris Mason
2009-04-09 10:28 ` Alasdair G Kergon
2009-03-26 12:55 ` Chris Mason
[not found] <ciXHh-39c-37@gated-at.bofh.it>
2009-03-23 21:52 ` Bodo Eggert
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=49C7DD3C.2020401@redhat.com \
--to=sandeen@redhat.com \
--cc=CHRIS.MASON@oracle.com \
--cc=ak@suse.de \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--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