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
test
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
xfs_db:
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?
t
--
thomas.graichen@xxxxxxxxxxxxxx
technical director innominate AG
clustering & security the linux architects
tel: +49-30-308806-13 fax: -77 http://www.innominate.com
|