On Nov 24, 6:50pm, Thomas Graichen wrote:
> Subject: alpha again
> just another try ... maybe someone has an idea now :-)
what does "xfs_db -r -c agf -c p /dev/sdb1" say at each
point (*) below.
> root@cyan:/usr/src/xfs/linux# 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:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
> root@cyan:/usr/src/xfs/linux# umount /mnt
> root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
> - zero log...
> - scan filesystem freespace and inode maps...
> bad magic # 0x0 for agf 0
> bad version # -1 for agf 0
> bad length 0 for agf 0, should be 4142
> flfirst -2147483648 in agf 0 too large (max = 128)
> reset bad agf for ag 0
> freeblk count 1 != flcount 1084270339 in ag 0
> bad agbno 2966461184 for btbno root, agno 0
> bad agbno 16580607 for btbcnt root, agno 0
> - found root inode chunk
> Phase 3 - for each AG...
> - scan and clear agi unlinked lists...
> - process known inodes and perform inode discovery...
> - agno = 0
> - agno = 1
> - agno = 2
> - agno = 3
and (*) here.
(could you send me the output in each place - thanks).
> looks for me a little bit like some kind of maybe size problems
> in some structure alignments or so ... aside from this i can
> run a dbench 64 without problems on the alpha ... looks
> like it's a more harmless and well located problem
I'm a little surprised that we can get thru dbench with what
seem like such fundamental problems... hmm - perhaps its only
a userspace problem (seeking to the wrong place or something).