All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heinz J. Mauelshagen" <Mauelshagen@Sistina.com>
To: Jens Axboe <axboe@suse.de>
Cc: Herbert Valerio Riedel <hvr@hvrlab.org>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>,
	linux-lvm-patch@EZ-Darmstadt.Telekom.de
Subject: Re: /dev/loop0 over lvm... leading to d-state :-(
Date: Thu, 5 Apr 2001 16:32:39 +0000	[thread overview]
Message-ID: <20010405163239.F6981@sistina.com> (raw)
In-Reply-To: <Pine.LNX.4.30.0104042152490.1183-100000@janus.txd.hvrlab.org> <20010405071313.A418@suse.de> <20010405163818.M418@suse.de> <20010405164942.N418@suse.de>
In-Reply-To: <20010405164942.N418@suse.de>; from axboe@suse.de on Thu, Apr 05, 2001 at 04:49:42PM +0200


Jens,

thanks for the b_dev hint you provided.

On Thu, Apr 05, 2001 at 04:49:42PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Jens Axboe wrote:
> > To the LVM folks: you can't use b_dev or b_blocknr inside your
> > make_request_fn, it destroys stacking drivers such as loop. And
> > is just plain wrong in the general case too.
> 
> Irks, another one. lvm_make_request_fn also needs to call b_end_io
> if a map fails.

This is wrong.

In case of an io error we do already call buffer_IO_error() on 2.4 in lvm_map().

In 2.2 ll_rw_block() does change the state of the buffer and calls
b_end_io() for us at the end of the function:

      sorry:
        for (i = 0; i < nr; i++) {
                if (bh[i]) {
                        clear_bit(BH_Dirty, &bh[i]->b_state);
                        clear_bit(BH_Uptodate, &bh[i]->b_state);
                        bh[i]->b_end_io(bh[i], 0);
                }
        }


> Updated patch attached, I'll collate further
> patches if I find more :-)

Please do that. Thanks again.

Regards,
Heinz    -- The LVM Guy --

>
> 
> -- 
> Jens Axboe
> 

> --- /opt/kernel/linux-2.4.3/drivers/md/lvm.c	Mon Jan 29 01:11:20 2001
> +++ drivers/md/lvm.c	Thu Apr  5 16:48:52 2001
> @@ -148,6 +148,9 @@
>   *                 procfs is always supported now. (JT)
>   *    12/01/2001 - avoided flushing logical volume in case of shrinking
>   *                 because of unecessary overhead in case of heavy updates
> + *    05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
> + *		   destroys stacking devices. call b_end_io on failed maps.
> + *		   (Jens Axboe)
>   *
>   */
>  
> @@ -1480,14 +1483,14 @@
>   */
>  static int lvm_map(struct buffer_head *bh, int rw)
>  {
> -	int minor = MINOR(bh->b_dev);
> +	int minor = MINOR(bh->b_rdev);
>  	int ret = 0;
>  	ulong index;
>  	ulong pe_start;
>  	ulong size = bh->b_size >> 9;
> -	ulong rsector_tmp = bh->b_blocknr * size;
> +	ulong rsector_tmp = bh->b_rsector;
>  	ulong rsector_sav;
> -	kdev_t rdev_tmp = bh->b_dev;
> +	kdev_t rdev_tmp = bh->b_rdev;
>  	kdev_t rdev_sav;
>  	vg_t *vg_this = vg[VG_BLK(minor)];
>  	lv_t *lv = vg_this->lv[LV_BLK(minor)];
> @@ -1676,8 +1679,12 @@
>   */
>  static int lvm_make_request_fn(request_queue_t *q,
>  			       int rw,
> -			       struct buffer_head *bh) {
> -	return (lvm_map(bh, rw) < 0) ? 0 : 1;
> +			       struct buffer_head *bh)
> +{
> +	int ret = lvm_map(bh, rw);
> +	if (ret)
> +		bh->b_end_io(bh, test_bit(BH_Uptodate, &bh->b_state));
> +	return ret;
>  }
>  
>  

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  reply	other threads:[~2001-04-05 15:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-04 20:00 /dev/loop0 over lvm... leading to d-state :-( Herbert Valerio Riedel
2001-04-05  5:13 ` Jens Axboe
2001-04-05 14:38   ` Jens Axboe
2001-04-05 14:49     ` Jens Axboe
2001-04-05 16:32       ` Heinz J. Mauelshagen [this message]
2001-04-05 15:37         ` Jens Axboe
2001-04-05 16:52           ` Heinz J. Mauelshagen
2001-04-05 15:54             ` Jens Axboe
2001-04-05 17:10               ` Heinz J. Mauelshagen

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=20010405163239.F6981@sistina.com \
    --to=mauelshagen@sistina.com \
    --cc=axboe@suse.de \
    --cc=hvr@hvrlab.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-lvm-patch@EZ-Darmstadt.Telekom.de \
    --cc=torvalds@transmeta.com \
    /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.