From: Jens Axboe <axboe@suse.de>
To: Herbert Valerio Riedel <hvr@hvrlab.org>
Cc: 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:38:18 +0200 [thread overview]
Message-ID: <20010405163818.M418@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.30.0104042152490.1183-100000@janus.txd.hvrlab.org> <20010405071313.A418@suse.de>
In-Reply-To: <20010405071313.A418@suse.de>; from axboe@suse.de on Thu, Apr 05, 2001 at 07:13:13AM +0200
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
On Thu, Apr 05 2001, Jens Axboe wrote:
> On Wed, Apr 04 2001, Herbert Valerio Riedel wrote:
> >
> > fyi, loop devices over lvm LV's dont work for me...
> >
> > I've tested with 2.4.3final (and some other 2.4.3 derivates) and two
> > lvm'ized partitions with a size of about 1gig each; mke2fs
> > just goes into D-state and stays there when applying it to /dev/loop0,
> > running it directly on the LV-device works...
>
> this would appear to be an lvm bug, could you try this patch? it's
> untested, let me know if it doesn't work and I'll try and reproduce
> here.
What do you know, there was one more in there. Even visible in
the original hunk :-). And this time it wasn't a loop bug (the
crowd goes bezerk).
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.
--
Jens Axboe
[-- Attachment #2: lvm-stack-1 --]
[-- Type: text/plain, Size: 952 bytes --]
--- /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:20:12 2001
@@ -148,6 +148,8 @@
* 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 - don't use b_blocknr/b_dev in lvm_map, it destroys
+ * stacking devices (Jens Axboe)
*
*/
@@ -1480,14 +1482,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)];
next prev parent reply other threads:[~2001-04-05 14:41 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 [this message]
2001-04-05 14:49 ` Jens Axboe
2001-04-05 16:32 ` Heinz J. Mauelshagen
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=20010405163818.M418@suse.de \
--to=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.