[Top] [All Lists]

Re: alpha again

To: linux-xfs@xxxxxxxxxxx
Subject: Re: alpha again
From: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>
Date: 30 Nov 2000 08:54:00 GMT
Distribution: local
Organization: innominate AG, Berlin, Germany
References: <news2mail-8vmd9o$upi$1@xxxxxxxxxxxxxxxxxxxxxx> <10011261353.ZM165451@xxxxxxxxxxxxxxxxxxxxxxxx> <news2mail-8vt4sn$dhv$2@xxxxxxxxxxxxxxxxxxxxxx> <10011280910.ZM168487@xxxxxxxxxxxxxxxxxxxxxxxx> <news2mail-90017k$n0b$1@xxxxxxxxxxxxxxxxxxxxxx> <10011300916.ZM156274@xxxxxxxxxxxxxxxxxxxxxxxx> <3A259273.D6353426@xxxxxxxxxxx>
Reply-to: Thomas Graichen <graichen@xxxxxxxxxxxxx>
Reply-to: thomas.graichen@xxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
Russell Cattelan <cattelan@xxxxxxxxxxx> wrote:
>> i think this would produce the behavior you're seeing here
>> - if the underlying device blocksize was 1024 and we wrote
>> out the (512 byte) superblock thinking the blocksize was
>> 512, well we'd end up putting random junk in the AGF since
>> thats the next 512 bytes right after the superblock.
>> if the blocksize does prove to be reset to something other
>> than 512, Thomas, could you try commenting out everything
>> between "/* Reset device block size */" and the end of the
>> function (linvfs_put_super) - 3/4 lines - and see if you
>> still see repair needing to fix the AGF after umount?

> It is entirely possible the ag is getting trashed the first time the
> super block is written out.  The file system will run just
> fine since most of the ag info is keep in memory and not
> re-read from disk.
> I suspect the partially valid page stuff is at fault.

> Try this mount a fresh file system.
> create a small file.
> run xfs_db -r <device>
> agf 0
> from man page:
> The AGF block is the header for block allocation
>                  information; it is in the second 512-byte  block
>                  of  each allocation group.  The following fields
>                  are defined:
>                  magicnum: AGF  block  magic  number,  0x58414746
>                  ('XAGF')

> If the magic number is wrong then we have trashed the block right off
> the bat.

root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
data     =                       bsize=8192   blocks=33130, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=8192  
log      =internal log           bsize=8192   blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0
root@cyan:~# mount /dev/sdb1 /mnt                                 
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: quit
root@cyan:~# echo test > /mnt/testfile
root@cyan:~# cat /mnt/testfile
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: agf 0
xfs_db: print
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 16777216
flcount = 97794
freeblks = 16580607
longest = 32258

so looks like you are right - i also double checked it - on the ppc for
instance the magicnum is 0x58414746 and also on the alpha in agf 1 -
any ideas where this might come from?


technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

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