From: Anders Henke <anders.henke@1und1.de>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
device-mapper development <dm-devel@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] Re: device mapper not reporting no-barrier-support?
Date: Tue, 26 Feb 2008 21:20:30 +0100 [thread overview]
Message-ID: <20080226202030.GR13026@1und1.de> (raw)
In-Reply-To: <20080226194122.GQ6704@kernel.dk>
On Tue, Feb 26 2008 schrieb Jens Axboe:
> On Tue, Feb 26 2008, Anders Henke wrote:
> > On Tue, Feb 26 2008 Jens Axboe wrote:
> > > On Tue, Feb 26 2008, Alasdair G Kergon wrote:
> > > > On Mon, Feb 25, 2008 at 03:20:50PM -0800, Andrew Morton wrote:
> > > > > On Mon, 25 Feb 2008 14:26:15 +0100 Anders Henke <anders.henke@1und1.de> wrote:
> > > > > > I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel
> > > > > > 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV).
> > > > > > -LVM2/device mapper doesn't support write barriers
> > > >
> > > > That's right.
> > > >
> > > > > > -DRBD uses blkdev_issue_flush() to flush its metadata to disk.
> > > >
> > > > Which won't work if device-mapper is underneath.
> > > >
> > > > > > On a no-barrier-device, DRBD should receive EOPNOTSUPP, but
> > > > > > it really does receive an EIO. Promptly, DRBD gives the
> > > > > > error message "drbd0: local disk flush failed with status -5".
> > > > > > I've posted a lengty summary of my findings to
> > > > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html
> > > > > > ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and
> > > > > > BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in
> > > > > > 2.6.24.2 aparently does return EIO for blkdev_issue_flush.
> > > > > I'd say it's a DM bug.
> > > >
> > > > The dm code is unchanged, but look at the limited endio handling in
> > > > ll_rw_blk.c:
> > > >
> > > > static void bio_end_empty_barrier(struct bio *bio, int err)
> > > > {
> > > > if (err)
> > > > clear_bit(BIO_UPTODATE, &bio->bi_flags);
> > > >
> > > > complete(bio->bi_private);
> > > > }
> > > >
> > > > int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector)
> > > > {
> > > > ...
> > > > wait_for_completion(&wait);
> > > > if (error_sector)
> > > > *error_sector = bio->bi_sector;
> > > > ret = 0;
> > > > if (!bio_flagged(bio, BIO_UPTODATE))
> > > > ret = -EIO;
> > >
> > > You are right, the return value got broken there. Does this make it
> > > return -EOPNOTSUPP properly for you?
> >
> >
> > No, it doesn't.
> >
> >
> >
> > I've applied your patch manually, as 2.6.24.2. doesn't have a "blk-barrier.c":
> >
> > ---cut
> > --- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11
> > 06:51:11.000000000 +0100
> > +++ linux-2.6.24.2/block/ll_rw_blk.c 2008-02-26 20:02:28.514641620
> > +0100
> > @@ -2667,8 +2667,11 @@
> >
> > static void bio_end_empty_barrier(struct bio *bio, int err)
> > {
> > - if (err)
> > + if (err) {
> > + if (err == -EOPNOTSUPP)
> > + set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
> > clear_bit(BIO_UPTODATE, &bio->bi_flags);
> > + }
> >
> > complete(bio->bi_private);
> > }
> > ---cut
> >
> > ... and the resulting kernel shows exactly the same behaviour than before:
>
> Not surprising, as you missed half of the patch:
Ouch. Thank you for pointing this out.
I've been spending too much time of the day with things who have a negative
impact on my concentration and I shouldn't manually patch kernels at
this time of the day.
Yes, it's useless to set a bit, but never check it (like in my version of
your patch).
After adding the second part of your patch, the resulting kernel works as
intended:
[ 234.946192] drbd0: conn( WFSyncUUID -> SyncTarget )
[ 234.956176] drbd0: Began resync as SyncTarget (will sync 19542404 KB
[4885601
bits set]).
[ 234.972567] drbd0: Writing meta data super block now.
[ 235.018203] drbd0: local disk flush failed with status -95
DRBD sees the EOPNOTSUPP, logs this message only once and doesn't try
any further barrier requests (as intended).
Just for the records, the 2.6.24.2-ready version of your patch:
---cut
--- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11 06:51:11.000000000 +0
100
+++ linux-2.6.24.2/block/ll_rw_blk.c 2008-02-26 20:58:05.552467940 +0100
@@ -2667,8 +2667,11 @@
static void bio_end_empty_barrier(struct bio *bio, int err)
{
- if (err)
+ if (err) {
+ if (err == -EOPNOTSUPP)
+ set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
clear_bit(BIO_UPTODATE, &bio->bi_flags);
+ }
complete(bio->bi_private);
}
@@ -2717,7 +2720,9 @@
*error_sector = bio->bi_sector;
ret = 0;
- if (!bio_flagged(bio, BIO_UPTODATE))
+ if (bio_flagged(bio, BIO_EOPNOTSUPP))
+ ret = -EOPNOTSUPP;
+ else if (!bio_flagged(bio, BIO_UPTODATE))
ret = -EIO;
bio_put(bio);
---cut
Anders
--
1&1 Internet AG better sleep(28800)
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
next prev parent reply other threads:[~2008-02-26 20:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-25 13:26 device mapper not reporting no-barrier-support? Anders Henke
2008-02-25 23:20 ` Andrew Morton
2008-02-25 23:20 ` Andrew Morton
2008-02-26 1:36 ` Alasdair G Kergon
2008-02-26 1:36 ` [dm-devel] " Alasdair G Kergon
2008-02-26 16:17 ` Jens Axboe
2008-02-26 19:33 ` Anders Henke
2008-02-26 19:41 ` Jens Axboe
2008-02-26 19:41 ` [dm-devel] " Jens Axboe
2008-02-26 20:20 ` Anders Henke [this message]
2008-02-26 22:25 ` Jens Axboe
2008-02-26 22:25 ` [dm-devel] " Jens Axboe
2008-02-28 12:05 ` Anders Henke
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=20080226202030.GR13026@1und1.de \
--to=anders.henke@1und1.de \
--cc=akpm@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.