Re: [linux-lvm] Problem mounting ext2 fs on LVM

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Jos Visser]

I have experienced this problem too. It has got something to do with
wrongly kept status in the LVM kernel module. If you unload/load
lvm-mod, everything is back to normal.

++Jos

And thus it came to pass that Urs Thuermann wrote:
(on Tue, Feb 27, 2001 at 04:23:33PM +0100 to be exact)

> After having decided that the performance problem I described in the
> other thread in this ML are probably not that important for me, I
> tried to create an ext2 fs with 1024 byte blocks on a 1 GB LV.
> 
> But I can't mount it after creating the fs.  I can mount it if I
> create it on sda5 instead of the LV, or if I chosse 4K block size.  I
> start with no VGs defined.
> 
> 1K block size on /dev/sda5 is ok:
> 
>     isnogud:/root# fdisk -l /dev/sda|grep sda5
>     /dev/sda5            80       399   2570368+  8e  Linux LVM
>     isnogud:/root# mke2fs -b 1024 /dev/sda5 1048576
>     mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
>     Filesystem label=
>     OS type: Linux
>     Block size=1024 (log=0)
>     Fragment size=1024 (log=0)
>     131072 inodes, 1048576 blocks
>     52428 blocks (5.00%) reserved for the super user
>     First data block=1
>     128 block groups
>     8192 blocks per group, 8192 fragments per group
>     1024 inodes per group
>     Superblock backups stored on blocks: 
>     	    8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553, 
>     	    1024001
>     
>     Writing inode tables: done                            
>     Writing superblocks and filesystem accounting information: done
>     isnogud:/root# mount /dev/sda5 /mnt
>     isnogud:/root# df /mnt
>     Filesystem           1k-blocks      Used Available Use% Mounted on
>     /dev/sda5              1031880        13    979439   0% /mnt
>     isnogud:/root# umount /mnt
> 
> But if I try the same on an LV, I get
> 
>     isnogud:/root# pvcreate /dev/sda5
>     pvcreate -- physical volume "/dev/sda5" successfully created
>     
>     isnogud:/root# vgcreate vg0 /dev/sda5
>     vgcreate -- INFO: using default physical extent size 4 MB
>     vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
>     vgcreate -- doing automatic backup of volume group "vg0"
>     vgcreate -- volume group "vg0" successfully created and activated
>     
>     isnogud:/root# lvcreate -n test /dev/vg0 -L 1024
>     lvcreate -- doing automatic backup of "vg0"
>     lvcreate -- logical volume "/dev/vg0/test" successfully created
>     
>     isnogud:/root# mke2fs -b 1024 /dev/vg0/test
>     mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
>     Filesystem label=
>     OS type: Linux
>     Block size=1024 (log=0)
>     Fragment size=1024 (log=0)
>     131072 inodes, 1048576 blocks
>     52428 blocks (5.00%) reserved for the super user
>     First data block=1
>     128 block groups
>     8192 blocks per group, 8192 fragments per group
>     1024 inodes per group
>     Superblock backups stored on blocks: 
>     	    8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553, 
>     	    1024001
>     
>     Writing inode tables: done                            
>     Writing superblocks and filesystem accounting information: done
>     isnogud:/root# mount /dev/vg0/test /mnt
>     mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
>     	   or too many mounted file systems
> 
> Any idea, what's wrong here?   I works, when I choose 4K block size:
> 
>     isnogud:/root# mke2fs -b 4096 /dev/vg0/test
>     mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
>     Filesystem label=
>     OS type: Linux
>     Block size=4096 (log=2)
>     Fragment size=4096 (log=2)
>     131072 inodes, 262144 blocks
>     13107 blocks (5.00%) reserved for the super user
>     First data block=0
>     8 block groups
>     32768 blocks per group, 32768 fragments per group
>     16384 inodes per group
>     Superblock backups stored on blocks: 
>     	    32768, 98304, 163840, 229376
>     
>     Writing inode tables: done                            
>     Writing superblocks and filesystem accounting information: done
>     isnogud:/root# mount /dev/vg0/test /mnt
>     isnogud:/root# df /mnt
>     Filesystem           1k-blocks      Used Available Use% Mounted on
>     /dev/vg0/test          1032088        20    979640   0% /mnt
>     isnogud:/root# umount /mnt
> 
> 
> urs
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 
Each betrayal begins with trust.

[linux-lvm] Problem mounting ext2 fs on LVM

[Urs Thuermann]

After having decided that the performance problem I described in the
other thread in this ML are probably not that important for me, I
tried to create an ext2 fs with 1024 byte blocks on a 1 GB LV.

But I can't mount it after creating the fs.  I can mount it if I
create it on sda5 instead of the LV, or if I chosse 4K block size.  I
start with no VGs defined.

1K block size on /dev/sda5 is ok:

    isnogud:/root# fdisk -l /dev/sda|grep sda5
    /dev/sda5            80       399   2570368+  8e  Linux LVM
    isnogud:/root# mke2fs -b 1024 /dev/sda5 1048576
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    Filesystem label=
    OS type: Linux
    Block size=1024 (log=0)
    Fragment size=1024 (log=0)
    131072 inodes, 1048576 blocks
    52428 blocks (5.00%) reserved for the super user
    First data block=1
    128 block groups
    8192 blocks per group, 8192 fragments per group
    1024 inodes per group
    Superblock backups stored on blocks: 
    	    8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553, 
    	    1024001
    
    Writing inode tables: done                            
    Writing superblocks and filesystem accounting information: done
    isnogud:/root# mount /dev/sda5 /mnt
    isnogud:/root# df /mnt
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/sda5              1031880        13    979439   0% /mnt
    isnogud:/root# umount /mnt

But if I try the same on an LV, I get

    isnogud:/root# pvcreate /dev/sda5
    pvcreate -- physical volume "/dev/sda5" successfully created
    
    isnogud:/root# vgcreate vg0 /dev/sda5
    vgcreate -- INFO: using default physical extent size 4 MB
    vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
    vgcreate -- doing automatic backup of volume group "vg0"
    vgcreate -- volume group "vg0" successfully created and activated
    
    isnogud:/root# lvcreate -n test /dev/vg0 -L 1024
    lvcreate -- doing automatic backup of "vg0"
    lvcreate -- logical volume "/dev/vg0/test" successfully created
    
    isnogud:/root# mke2fs -b 1024 /dev/vg0/test
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    Filesystem label=
    OS type: Linux
    Block size=1024 (log=0)
    Fragment size=1024 (log=0)
    131072 inodes, 1048576 blocks
    52428 blocks (5.00%) reserved for the super user
    First data block=1
    128 block groups
    8192 blocks per group, 8192 fragments per group
    1024 inodes per group
    Superblock backups stored on blocks: 
    	    8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553, 
    	    1024001
    
    Writing inode tables: done                            
    Writing superblocks and filesystem accounting information: done
    isnogud:/root# mount /dev/vg0/test /mnt
    mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
    	   or too many mounted file systems

Any idea, what's wrong here?   I works, when I choose 4K block size:

    isnogud:/root# mke2fs -b 4096 /dev/vg0/test
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    131072 inodes, 262144 blocks
    13107 blocks (5.00%) reserved for the super user
    First data block=0
    8 block groups
    32768 blocks per group, 32768 fragments per group
    16384 inodes per group
    Superblock backups stored on blocks: 
    	    32768, 98304, 163840, 229376
    
    Writing inode tables: done                            
    Writing superblocks and filesystem accounting information: done
    isnogud:/root# mount /dev/vg0/test /mnt
    isnogud:/root# df /mnt
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/vg0/test          1032088        20    979640   0% /mnt
    isnogud:/root# umount /mnt


urs

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Urs Thuermann]

Jos Visser <josv@osp.nl> writes:

> I have experienced this problem too. It has got something to do with
> wrongly kept status in the LVM kernel module. If you unload/load
> lvm-mod, everything is back to normal.

I just wanted to follow up my own posting since I have also tried to
unload/load the module and found out it works again.  This might be a
problem however, if you have some essential file systems on LVM so you
can't unload the module.

Has that bug already been found and is it being fixed?


urs

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Jos Visser]

Thus far, I have been too lazy to dive into the code. However, what I
had not found out, and what is an important clue I guess, is that it
*does* work with a 4KB block size.

++Jos

And thus it came to pass that Urs Thuermann wrote:
(on Tue, Feb 27, 2001 at 05:14:03PM +0100 to be exact)

> Jos Visser <josv@osp.nl> writes:
> 
> > I have experienced this problem too. It has got something to do with
> > wrongly kept status in the LVM kernel module. If you unload/load
> > lvm-mod, everything is back to normal.
> 
> I just wanted to follow up my own posting since I have also tried to
> unload/load the module and found out it works again.  This might be a
> problem however, if you have some essential file systems on LVM so you
> can't unload the module.
> 
> Has that bug already been found and is it being fixed?
> 
> 
> urs
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 
Each betrayal begins with trust.

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Joe Thornber]

On Tue, Feb 27, 2001 at 08:21:55AM -0800, Jos Visser wrote:
> Thus far, I have been too lazy to dive into the code. However, what I
> had not found out, and what is an important clue I guess, is that it
> *does* work with a 4KB block size.

This is a known bug (look in KNOWN_BUGS).  I'm not sure where the
persistent value is.

- Joe

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Andreas Dilger]

Urs writes:
> After having decided that the performance problem I described in the
> other thread in this ML are probably not that important for me, I
> tried to create an ext2 fs with 1024 byte blocks on a 1 GB LV.
> 
> But I can't mount it after creating the fs.  I can mount it if I
> create it on sda5 instead of the LV, or if I choose 4K block size.
> 
>     isnogud:/root# mount /dev/vg0/test /mnt
>     mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
>     	   or too many mounted file systems

What does it say in the syslog?  This will tell you why ext2 thinks it
can't mount, and will give us a clue on how to fix LVM.  I'm guessing
that when ext2 tries to set the blocksize to 1k it fails.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Urs Thuermann]

Andreas Dilger <adilger@turbolinux.com> writes:

> What does it say in the syslog?  This will tell you why ext2 thinks it
> can't mount, and will give us a clue on how to fix LVM.  I'm guessing
> that when ext2 tries to set the blocksize to 1k it fails.

Yes, I have a couple of messages in my syslog, like

Feb 27 17:04:39 isnogud kernel: VFS: Unsupported blocksize on dev lvm(58,0).


urs

Re: [linux-lvm] Problem mounting ext2 fs on LVM

[Andreas Dilger]

Urs writes:
> Andreas Dilger <adilger@turbolinux.com> writes:
> > What does it say in the syslog?  This will tell you why ext2 thinks it
> > can't mount, and will give us a clue on how to fix LVM.  I'm guessing
> > that when ext2 tries to set the blocksize to 1k it fails.
> 
> Yes, I have a couple of messages in my syslog, like
> 
> Feb 27 17:04:39 isnogud kernel: VFS: Unsupported blocksize on dev lvm(58,0).

This is an ext2 message when sb->s_blocksize != bh->b_size, even though
ext2 _should_ set the block size correctly if we get to this point (it
will call set_blocksize(sb->s_blocksize)).

Now I see what the problem might be, it is in ext2.  Give it a try and
let me know how it goes.

Cheers, Andreas
==========================================================================
--- fs/ext2/super.c.orig	Fri Feb  2 17:12:09 2001
+++ fs/ext2/super.c	Tue Feb 27 12:53:41 2001
@@ -787,7 +791,7 @@
 	
 	sb->s_maxbytes = ext2_max_size(sb->s_blocksize_bits);
 	
-	if (sb->s_blocksize != BLOCK_SIZE &&
+	if (sb->s_blocksize != blocksize &&
 	    (sb->s_blocksize == 1024 || sb->s_blocksize == 2048 ||
 	     sb->s_blocksize == 4096)) {
 		/*
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

[linux-lvm] Bugs in LVM and ext2 + suggestion for fix (was: Problem mounting ext2 fs on LVM)

[Urs Thuermann]

For LKML readers: I had a problem mounting an ext2 FS on LVM with 1K
block size while 4K block size did work.  I'd like answers CC:'ed to
the LVM ML or, if there inapproriate there, to me, since I currently
do not read LKML.

I've read lots of EXT2 and LVM src code and I think it turns out that
there is a bug in both.  Andreas has already given the fix for the
ext2, a suggestion for LVM is below (sorry, no patch, I really know to
little about all the block sizes and buffers of block devices).


Andreas Dilger <adilger@turbolinux.com> writes:

>Urs writes:
>
>> Feb 27 17:04:39 isnogud kernel: VFS: Unsupported blocksize on dev lvm(58,0).
>
> This is an ext2 message when sb->s_blocksize != bh->b_size, even though
> ext2 _should_ set the block size correctly if we get to this point (it
> will call set_blocksize(sb->s_blocksize)).
> 
> Now I see what the problem might be, it is in ext2.  Give it a try and
> let me know how it goes.
> 
> Cheers, Andreas
> ==========================================================================
> --- fs/ext2/super.c.orig	Fri Feb  2 17:12:09 2001
> +++ fs/ext2/super.c	Tue Feb 27 12:53:41 2001
> @@ -787,7 +791,7 @@
> 	  
> 	  sb->s_maxbytes = ext2_max_size(sb->s_blocksize_bits);
> 	  
> -	if (sb->s_blocksize != BLOCK_SIZE &&
> +	if (sb->s_blocksize != blocksize &&
> 	      (sb->s_blocksize == 1024 || sb->s_blocksize == 2048 ||
> 	       sb->s_blocksize == 4096)) {
> 		  /*


I think your patch is right and should be sent to the ext2
maintainers.  The condition to test should indeed be, wether the block
size in the super block is one of the known size 1K, 2K or 4K, and if
it is different from the block size (hardsect_size[]) of the block
device.  If so, the block size of the device (blksize_size[]) should
be set by calling set_blocksize(dev, sb->s_blocksize) and a new
buffer_head obtained by bh=bread(...,sb->s_blocksize)

BTW, can someone tell what the purpose having blksize_size[] and
hardsect_size[] is?


Anyway, I think your patch doesn't solve my problem with LVM, though I
haven't tried it yet.

The problem is, that mounting an ext2 fs on a LV (like on any other
block device), where the ext2 block size is greater than the
hardsect_size of the device causes the ext2 code to call
set_blocksize() on the device which then sets the blksize_size[] entry
for that device.

With LVM, blksize_size[MAJOR] and hardsect_size[MAJOR] point to the
same array, namely lvm_blocksizes[], which are initialized to
BLOCK_SIZE (1024).  

    void __init lvm_geninit(struct gendisk *lvm_gdisk)
    {
	
    	    ...
    	    for (i = 0; i < MAX_LV; i++) {
    		    ...
    		    lvm_blocksizes[i] = BLOCK_SIZE;
    	    }
    
    	    blk_size[MAJOR_NR] = lvm_size;
    	    blksize_size[MAJOR_NR] = lvm_blocksizes;
    	    hardsect_size[MAJOR_NR] = lvm_blocksizes;
    
    	    return;
    } /* lvm_gen_init() */
    
Mounting an ext2 FS therefore causes not only the
blksize_size[MAJOR(dev)][MINOR(dev)] but also the
hardsect_size[MAJOR(dev)][MINOR(dev)] to be increased to the ext2
block size.  And this can't never be reduced to BLOCK_SIZE again,
except by unloading/loading the LVM module which initializes
lvm_blocksizes[].

This means, I can mount an ext2 FS with 1K block size on a specific
major/minor after loading the LVM module.  If I mount a FS with a
larger block size, the hardsect_size[] is increased and from then on I
can only mount file systems with@least the same block size.
I.e. after mounting an ext2 FS with 2K block size, I can only mount 2K
and 4K ext2 file systems.  After mounting 4K ext2 FS I can only mount
4K ext2 file systems.

With a freshly loaded LVM module I do

    isnogud:/root# vgcreate vg0 /dev/sda5; lvcreate -n test vg 0 -L1024
    [...]
    isnogud:/root# mke2fs -q /dev/vg0/test -b 1024
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    isnogud:/root# umount /mnt
    isnogud:/root# mke2fs -q /dev/vg0/test -b 2048
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    isnogud:/root# umount /mnt
    isnogud:/root# mke2fs -q /dev/vg0/test -b 1024
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
    	   or too many mounted file systems

The kernel log says (I have slighty modified the msg fmt in
ext2/super.c to also print sb->s_blocksize and bh->b_size):

    VFS: Unsupported blocksize on dev lvm(58,0) (1024!=2048).

At this point I can still mount ext2 FS with 2K block size.  OK, now I
mount a FS with 4K block size:

    isnogud:/root# mke2fs -q /dev/vg0/test -b 4096
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    isnogud:/root# umount /mnt

From now on, I can't mount file systems with 1K or 2K block size,
since the hardsect_size[][] is now 4K:

    isnogud:/root# mke2fs -q /dev/vg0/test -b 1024
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
    	   or too many mounted file systems
    isnogud:/root# dmesg|tail -1
    VFS: Unsupported blocksize on dev lvm(58,0) (1024!=4096).
    isnogud:/root# mke2fs -q /dev/vg0/test -b 2048
    mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
    isnogud:/root# mount /dev/vg0/test /mnt
    mount: wrong fs type, bad option, bad superblock on /dev/vg0/test,
    	   or too many mounted file systems
    isnogud:/root# dmesg|tail -1
    EXT2-fs: blocksize too small for device.

Because of the wrong? test in fs/ext2/super.c (BLOCK_SIZE instead of
blocksize) the log message "Unsupported blocksize..." is printed
where I assume it should be "EXT2-fs: blocksize too small...", since
the hardsect_size[][] of the LVM device is 2K or 4K which is *not*
unsupported but to large for a file system with smaller blocks.



I think the solution for LVM is to have blksize_size[] and
hardsect_size[] not point to the same lvm_blocksizes[] array, but to
have a separate lvm_hardsect_size[] which is not affected by
set_blocksize().

However, I don't quite understand what the reason for having separate
blksize_size[] and hardsect_size[] is and how the bh->b_size differs
from that.  I assume the hardsect_size[] is the hardware sector size
of the physical device, but what's the purpose of blksize_size[]?
AFAICS, with bread(dev,block,size) I get a struct buffer_head, whose
b_size is set to the size arguement.  I guess via this buffer_head I
can access the device as it would have b_size blocks instead of
hardsect_size[] sectors.

Can two different users access the same block device with different
block sizes if they have an own buffer_head each?  And again, what is
blksize_size[] for, then?


urs

Re: [linux-lvm] Bugs in LVM and ext2: patch for LVM

[Urs Thuermann]

Urs Thuermann <urs@isnogud.escape.de> writes:

> I've read lots of EXT2 and LVM src code and I think it turns out that
> there is a bug in both.  Andreas has already given the fix for the
> ext2, a suggestion for LVM is below (sorry, no patch, I really know to
> little about all the block sizes and buffers of block devices).

Despite my limited knowledge of the src code for buffering and block
devices I have made an patch which fixes the LVM problem for me.  I'm
not 100% sure it is correct and if it is the clean solution.  Some
kernel god should therefore take a look on it.  At least I have
running it here in my kernel.


--- linux-2.4.2/drivers/md/lvm.c.orig	Wed Feb 28 18:27:40 2001
+++ linux-2.4.2/drivers/md/lvm.c	Wed Feb 28 17:00:25 2001
@@ -376,6 +376,8 @@
 static struct hd_struct lvm_hd_struct[MAX_LV];
 static int lvm_blocksizes[MAX_LV] =
 {0,};
+static int lvm_hardsizes[MAX_LV] =
+{0,};
 static int lvm_size[MAX_LV] =
 {0,};
 static struct gendisk lvm_gendisk =
@@ -3035,11 +3037,12 @@
 		lvm_gendisk.part[i].start_sect = -1;	/* avoid partition check */
 		lvm_size[i] = lvm_gendisk.part[i].nr_sects = 0;
 		lvm_blocksizes[i] = BLOCK_SIZE;
+		lvm_hardsizes[i] = BLOCK_SIZE;
 	}
 
 	blk_size[MAJOR_NR] = lvm_size;
 	blksize_size[MAJOR_NR] = lvm_blocksizes;
-	hardsect_size[MAJOR_NR] = lvm_blocksizes;
+	hardsect_size[MAJOR_NR] = lvm_hardsizes;
 
 	return;
 } /* lvm_gen_init() */

Re: [linux-lvm] Bugs in LVM and ext2: patch for LVM

[Joe Thornber]

Urs,

Could you try the latest code from CVS ? (to be released tomorrow),
since Andrea Arcangeli has already supplied a similar patch.

- Joe


On Wed, Feb 28, 2001 at 06:53:33PM +0100, Urs Thuermann wrote:
> Urs Thuermann <urs@isnogud.escape.de> writes:
> 
> > I've read lots of EXT2 and LVM src code and I think it turns out that
> > there is a bug in both.  Andreas has already given the fix for the
> > ext2, a suggestion for LVM is below (sorry, no patch, I really know to
> > little about all the block sizes and buffers of block devices).
> 
> Despite my limited knowledge of the src code for buffering and block
> devices I have made an patch which fixes the LVM problem for me.  I'm
> not 100% sure it is correct and if it is the clean solution.  Some
> kernel god should therefore take a look on it.  At least I have
> running it here in my kernel.
> 
> 
> --- linux-2.4.2/drivers/md/lvm.c.orig	Wed Feb 28 18:27:40 2001
> +++ linux-2.4.2/drivers/md/lvm.c	Wed Feb 28 17:00:25 2001
> @@ -376,6 +376,8 @@
>  static struct hd_struct lvm_hd_struct[MAX_LV];
>  static int lvm_blocksizes[MAX_LV] =
>  {0,};
> +static int lvm_hardsizes[MAX_LV] =
> +{0,};
>  static int lvm_size[MAX_LV] =
>  {0,};
>  static struct gendisk lvm_gendisk =
> @@ -3035,11 +3037,12 @@
>  		lvm_gendisk.part[i].start_sect = -1;	/* avoid partition check */
>  		lvm_size[i] = lvm_gendisk.part[i].nr_sects = 0;
>  		lvm_blocksizes[i] = BLOCK_SIZE;
> +		lvm_hardsizes[i] = BLOCK_SIZE;
>  	}
>  
>  	blk_size[MAJOR_NR] = lvm_size;
>  	blksize_size[MAJOR_NR] = lvm_blocksizes;
> -	hardsect_size[MAJOR_NR] = lvm_blocksizes;
> +	hardsect_size[MAJOR_NR] = lvm_hardsizes;
>  
>  	return;
>  } /* lvm_gen_init() */
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
>