No subject

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