Problem mounting ext2 fs on LVM
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
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)
Quoted 104 lines
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/sda5is 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, 1024001Writing 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/sda51031880 13 979439 0% /mnt
isnogud:/root# umount /mntBut if I try the same on an LV, I get
isnogud:/root# pvcreate /dev/sda5 pvcreate -- physical volume "/dev/sda5" successfully createdisnogud:/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 activatedisnogud:/root# lvcreate -n test /dev/vg0 -L 1024 lvcreate -- doing automatic backup of "vg0" lvcreate -- logical volume "/dev/vg0/test" successfully createdisnogud:/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, 1024001Writing 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 systemsAny 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, 229376Writing 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/test1032088 20 979640 0% /mnt
isnogud:/root# umount /mnturs
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Signature · 1 line
Each betrayal begins with trust.
Quoted 3 lines · 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.
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
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)
Quoted 19 lines
Quoted 3 lines · 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.
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
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Signature · 1 line
Each betrayal begins with trust.
Quoted 3 lines · 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.
This is a known bug (look in KNOWN_BUGS). I'm not sure where the persistent value is.
- Joe
Quoted 10 lines · Urs
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
Signature · 3 lines
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/ -- DogbertQuoted 3 lines · Andreas Dilger
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
Quoted 8 lines · Urs
Quoted 3 lines · Andreas Dilger
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
==========================================================================
ext2/super.c renamed from ext2/super.c.orig +1 -1
@@ -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 )) {/*
Signature · 3 lines
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/ -- DogbertBugs in LVM and ext2 + suggestion for fix (was: Problem mounting ext2 fs on LVM)
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).
Quoted 16 lines · Andreas Dilger
Quoted 1 line · Urs
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 callset_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
==========================================================================
ext2/super.c line 797
Quoted 8 lines
ext2/super.c renamed from ext2/super.c.orig +1
-1@@ -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 systemsThe 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 /mntFrom 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
In reply to Andreas DilgerQuoted 4 lines · Urs Thuermann
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.
drivers/md/lvm.c renamed from drivers/md/lvm.c.orig +4 -1
@@ -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
Urs,
Could you try the latest code from CVS ? (to be released tomorrow), since Andrea Arcangeli has already supplied a similar patch.
- Joe
Quoted 44 lines · Urs Thuermann
Quoted 4 lines · Urs Thuermann
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.
drivers/md/lvm.c renamed from drivers/md/lvm.c.orig +4
-1@@ -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
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm