All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Anders Henke <anders.henke@1und1.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	device-mapper development <dm-devel@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Re: device mapper not reporting no-barrier-support?
Date: Tue, 26 Feb 2008 20:41:22 +0100	[thread overview]
Message-ID: <20080226194122.GQ6704@kernel.dk> (raw)
In-Reply-To: <20080226193349.GQ13026@1und1.de>

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:

> > @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector)
> >  		*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);

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: Anders Henke <anders.henke@1und1.de>,
	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 20:41:22 +0100	[thread overview]
Message-ID: <20080226194122.GQ6704@kernel.dk> (raw)
In-Reply-To: <20080226193349.GQ13026@1und1.de>

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:

> > @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector)
> >  		*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);

-- 
Jens Axboe


  reply	other threads:[~2008-02-26 19:41 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 [this message]
2008-02-26 19:41           ` Jens Axboe
2008-02-26 20:20           ` Anders Henke
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=20080226194122.GQ6704@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=anders.henke@1und1.de \
    --cc=dm-devel@redhat.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.