xfs
[Top] [All Lists]

Re: stress test on ppc

To: Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx
Subject: Re: stress test on ppc
From: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 28 Nov 2000 10:48:43 -0400
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> "Re: stress test on ppc" (Nov 27, 8:27am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com> <20001110094151.C333@ysabell> <10011110006.ZM127189@wobbly.melbourne.sgi.com> <news2mail-8uo7od$4lt$1@mate.bln.innominate.de> <10011141059.ZM128320@wobbly.melbourne.sgi.com> <news2mail-8utlfv$8iu$1@mate.bln.innominate.de> <10011221244.ZM158790@wobbly.melbourne.sgi.com> <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> <10011261336.ZM166460@wobbly.melbourne.sgi.com> <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>
Sender: owner-linux-xfs@xxxxxxxxxxx
hi,

On Nov 27,  8:27am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> > ...
> > I don't understand how one could get a blocksize like
> > that since the test runs mkfs.xfs on the scratch device
> > and so should always have a blocksize of 4K (by default)
> > - see _populate_scratch() in the test, followed by the
> > blksize=... line a little further down.
> 
> ah - i have an idea here: i'm currently using the ide driver from the
> ppc linux tree - where i had to add the
> 
>   case BLKSETSIZE:
> 
> to ide_ioctl in ide.c - maybe i have missed something there - but
> from the diffs there was nothing suspect between the two ide drivers
> which let me think of something too different ...
> 

no, thats not it.  the (filesystem) blocksize comes from mkfs.xfs
and is written into all of the superblocks using the value which
mkfs calculates.  By default (which is the case, in test 004)
this is (1<<XFS_DFL_BLOCKSIZE_LOG)... 4096.  you could trace the
value of the "blocksize" variable in xfs_mkfs.c ... it eventually
gets stuffed into the primary sb (line 1390) and written to disk
(line 1499).

so running xfs_db after doing mkfs.xfs with no blksize options
(as in test 004 - populate_scratch() routine) should always show
the blocksize as 4096.  what i don't understand is how we've ended
up with a non-default (but valid) blocksize after doing a default
mkfs.

> >> > (btw, any luck with ppc mount detecting a minix filesystem?)
> >> 
> >> sorry- looks like this was my fault: minix fs was simply not compiled
> >> into the kernel :-(
> 
> > no, that wouldn't affect this test - its all user space
> > testing of mkfs (no actual mount happens), so no kernel
> > support for other filesystems is required.
> 
> >> ... works now
> 
> > *shrug* - must have been an alignment-of-the-planets issue.
> 
> no - you are right - the test still fails ... hm - but mount works
> now with minix ... i think this is what you were talking about:
> 
> ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t minix /dev/hda9
> 21856 inodes
> 65535 blocks
> Firstdatazone=696 (696)
> Zonesize=1024
> Maxsize=268966912
> 
> ppc:/usr/src/xfs/cmd/xfs/stress # mount /dev/hda9 /mnt

yup - thats it ... looks like your mount does auto-detect
minix somehow.  hmmm... i'll need to go see whats different
between your mount code and the mkfs/mountinfo.c code.  which
version of mount are you using?  (mount -V?)

> ppc:/usr/src/xfs/cmd/xfs/stress # mount | grep /mnt
> /dev/hda9 on /mnt type minix (rw)
> ppc:/usr/src/xfs/cmd/xfs/stress # umount /mnt
> ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t xfs /dev/hda9
> meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
> data     =                       bsize=4096   blocks=393216, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> ppc:/usr/src/xfs/cmd/xfs/stress #
> 
> btw. i'm not shure if it really is only usermode - i think at least
> the suse mount seems to require fs support (maybe looking into
> /proc/filesystems - suse has no /etc/filesystems for instance) for
> the mount fs detection - otherwise you get a "wrong major ..."
> 

is Suse mount based on Andries Brouwers' util-linux mount code?
I'd be surprised if not.  This looks in all sorts of places to
try and figure out the filesystem type (including procfs & /etc,
but also by probing).   Its this probing code which mkfs.xfs
uses in order to try not write on an existing filesystem.

do you see something like this on powerpc?...
10:11 nathans@troppo ~/src/util-linux-2.10q/mount 49> sudo mkfs -t minix 
/dev/hdb9
21856 inodes
65535 blocks
Firstdatazone=696 (696)
Zonesize=1024
Maxsize=268966912

10:12 nathans@troppo ~/src/util-linux-2.10q/mount 50> sudo od -j 1024 -x -N 32 
/dev/hdb9
0002000 5560 ffff 0003 0008 02b8 0000 1c00 1008
0002020 138f 0001 0000 0000 0000 0000 0000 0000
        ^^^^
0002040
10:12 nathans@troppo ~/src/util-linux-2.10q/mount 51> 

the 0x138f is the minix magic number which the mount "probe"
code is looking for.

hmmm .... i think this is going to be an endian problem in
mount.  in particular this mount_guess_fstype.c code looks
suspect:

    else if (minixmagic(sb.ms) == MINIX_SUPER_MAGIC
             || minixmagic(sb.ms) == MINIX_SUPER_MAGIC2)
         type = "minix";

especially compared to the ext2 code immediately above it
(this same code is in cmd/xfs/mkfs/mountinfo.c).

cheers.

-- 
Nathan

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