xfs
[Top] [All Lists]

Re: alpha again

To: linux-xfs@xxxxxxxxxxx
Subject: Re: alpha again
From: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>
Date: 28 Nov 2000 10:25:56 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>
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))
"Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
...
> heh - thats completely bogus.  so the problem is in the kernel
> (xfs mount/umount code paths) after all.
...
> my next best guess at the probable cause is that this may
> be a blocksize related problem.  we know that the primary
> superblock is pretty much intact (otherwise xfs_db would have
> gone haywire) - but since its offset is at start of blk 0,
> we're always likely to get that right no matter what the page
> & blksizes are, I think.
...
> I need two more things, then I'll have to go read the code
> some & get back to you:
> - run "xfs_db -r -c sb -c p /dev/sdb1" after the mkfs, so I
> know where we're starting from (primary sb);
> - run "xfs_db -r -c agf -c p /dev/sdb1" again, but in-between
> the mount and umount (there are writes on the mount path too,
> with any luck we'll see corruption early on which should make
> it easier to diagnose).

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:~# xfs_db -r -c sb -c p /dev/sdb1
magicnum = 0x58465342
blocksize = 8192
dblocks = 33130
rblocks = 0
rextents = 0
uuid = f30502a5-d2fd-490a-b915-2b48635e5d88
logstart = 32772
rootino = 256
rbmino = 257
rsumino = 258
rextsize = 8
agblocks = 4142
agcount = 8
rbmblocks = 0
logblocks = 1000
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 32
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 13
sectlog = 9
inodelog = 8
inopblog = 5
agblklog = 13
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 32096
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1
unit = 0
width = 0
dirblklog = 0
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# mount /dev/sdb1 /mnt; xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# umount /mnt
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 0
flcount = 1080068612
freeblks = 16580607
longest = 6326788
root@cyan:~# 

so looks like the umount code trashes things - this would also make
clear why xfs survives the dbench 64 - the filesystem seems to be
stable while operating and only gets trashed on umount ...

t

-- 
thomas.graichen@xxxxxxxxxxxxxx
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>