Not sending this to the bug system.....
>
> <quick diversion>
> I noticed xfs seems to set the device blocksize to 512 explicitly
> (in linvfs_readsuper) ... that seems odd to me - why aren't we
> driving this either from the superblock blocksize value or to
> the value from get_hardblocksize()? - does that code look right
> to you?
XFS needs 512 byte access for things like the super block, agi/agf
header structures. We are forced into using the lowest common denominator
block size because of this - the fact that the log may require us to
pin one in memory whilst forcing the other out means we cannot just do
a larger I/O.
>
> The xfs put_super code also looks like it should be calling
> get_hardblocksize() rather than accessing hardsect_size[] directly,
> perhaps?
This is probably true, get_hardblocksize probably showed up after the
initial code was written, or I just didn't notice it being there.
>
> Having spent all of 10 minutes looking at this code, I could well
> be way off on these above two statements though ;-)
> </end diversion>
>
>
> OK, so given we have removed the last-potential-efs-sb overwrite in
> mkfs.xfs, the remaining question is whether writing the external log
> device (i.e. zeroing & footering it) is affected as well.
>
> This experiment seems to suggest that we are not affected here
> either... (hda10 and hda11 both have sizes which are _not_ multiples
> of 4K):
>
> [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda10
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp
> [nathans@troppo mkfs]# umount /mnt/tmp
> [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp
> [nathans@troppo mkfs]# umount /mnt/tmp
>
> ...ext2 has now called set_blocksize(4096) on both devices.
>
> [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10
> mkfs.xfs: write failed: No space left on device
> [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11
> mkfs.xfs: write failed: No space left on device
>
> ...as expected, these both fail with the old mkfs binary.
>
> [nathans@troppo mkfs]# mkfs -t ext2 -b 1024 -q /dev/hda10
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp
> [nathans@troppo mkfs]# umount /mnt/tmp
> [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp
> [nathans@troppo mkfs]# umount /mnt/tmp
>
> we can now expect to succeed on hda10, but not hda11...
>
> [nathans@troppo mkfs]# ./mkfs.xfs -f -q -l logdev=/dev/hda11 /dev/hda10
> [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11
> mkfs.xfs: write failed: No space left on device
> [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10
> [nathans@troppo mkfs]#
>
> ... eureka - no error for the external log case!
>
> For bonus points, someone gets to explain why this is... cos I
> thought it would fail. Anyway, my head hurts ;) - I'll have to
> figure this one out tomorrow.
>
> Maximum blocksize which can be set in the kernel is PAGE_SIZE,
> so there may be issues at 8192 too, for some architectures ...
> mkfs.ext2 wont take us there though (disallows 8192 as a block
> size).
>
> cheers.
This one is wierd, I would expect the same error. I think this is a problem
we need to fix in some other way eventually. The /dev/raw suggestion is a
good one, probably not something we want to release without some testing
though. I presume this would be something we could encapsulate in the
libxfs device open and close code - we create a /dev/raw device for the
partition and use that descriptor rather than opening the device directly.
Steve
|