xfs
[Top] [All Lists]

Re: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fai

To: nathans@xxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Subject: Re: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail
From: Steve Lord <lord@xxxxxxx>
Date: Mon, 11 Sep 2000 09:36:29 -0500
In-reply-to: Message from pv@odin.corp.sgi.com (nathans@engr.sgi.com) of "Sun, 10 Sep 2000 22:39:16 PDT." <200009110539.WAA87342@info.engr.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
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






<Prev in Thread] Current Thread [Next in Thread>