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...
greetings,
--
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.
--
Jens Axboe
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
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. Updated patch attached, I'll collate further
patches if I find more :-)
--
Jens Axboe
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
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > 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().
Where? Calling buffer_IO_error would be ok, but there are no such calls
in 2.4.3. I just stated elsewhere that submit_bh should probably be
clearing the dirty bit, not ll_rw_block, in which case the b_end_io
is fine. But buffer_IO_error is probably more clear. I trust you'll
take care of that part then.
--
Jens Axboe
On Thu, Apr 05, 2001 at 05:37:31PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > > 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().
>
> Where? Calling buffer_IO_error would be ok, but there are no such calls
> in 2.4.3. I just stated elsewhere that submit_bh should probably be
> clearing the dirty bit, not ll_rw_block, in which case the b_end_io
> is fine. But buffer_IO_error is probably more clear. I trust you'll
> take care of that part then.
Sorry, didn't mention that you need to patch the driver with the recent
LVM software in order to get it.
I've send the patch a while ago to Linus to get it into 2.4.3
but he obviously didn't include it (likely because he thought it was too
large ;-)
He didn't comment back to me at all though :-(
Maybe this will help.
Linus?
>
> --
> Jens Axboe
>
--
Regards,
Heinz -- The LVM Guy --
*** 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
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > Where? Calling buffer_IO_error would be ok, but there are no such calls
> > in 2.4.3. I just stated elsewhere that submit_bh should probably be
> > clearing the dirty bit, not ll_rw_block, in which case the b_end_io
> > is fine. But buffer_IO_error is probably more clear. I trust you'll
> > take care of that part then.
>
> Sorry, didn't mention that you need to patch the driver with the recent
> LVM software in order to get it.
Ah ok, so the b_dev/b_blocknr is all then. Good.
> I've send the patch a while ago to Linus to get it into 2.4.3
> but he obviously didn't include it (likely because he thought it was too
> large ;-)
Maybe you're hanging on to fixes and submitting huge chunks of them?
> He didn't comment back to me at all though :-(
> Maybe this will help.
Two things that usually help -- submit small and often, then resubmit,
resubmit, resubmit until he takes it or complains loudly :-)
--
Jens Axboe
On Thu, Apr 05, 2001 at 05:54:30PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > > Where? Calling buffer_IO_error would be ok, but there are no such calls
> > > in 2.4.3. I just stated elsewhere that submit_bh should probably be
> > > clearing the dirty bit, not ll_rw_block, in which case the b_end_io
> > > is fine. But buffer_IO_error is probably more clear. I trust you'll
> > > take care of that part then.
> >
> > Sorry, didn't mention that you need to patch the driver with the recent
> > LVM software in order to get it.
>
> Ah ok, so the b_dev/b_blocknr is all then. Good.
>
> > I've send the patch a while ago to Linus to get it into 2.4.3
> > but he obviously didn't include it (likely because he thought it was too
> > large ;-)
>
> Maybe you're hanging on to fixes and submitting huge chunks of them?
We want to change that, sorry :)
>
> > He didn't comment back to me at all though :-(
> > Maybe this will help.
>
> Two things that usually help -- submit small and often, then resubmit,
> resubmit, resubmit until he takes it or complains loudly :-)
I know, I know, I know ;-)
>
> --
> Jens Axboe
>
--
Regards,
Heinz -- The LVM Guy --
*** 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
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-