[Top] [All Lists]

Re: Read corruption on ARM

To: Jason Detring <detringj@xxxxxxxxx>
Subject: Re: Read corruption on ARM
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 27 Feb 2013 11:00:34 -0600
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CA+AKrqCrphO-eKy0n=70O9hmB3mXttOsKmTdfRnPxgJM3_PAkQ@xxxxxxxxxxxxxx>
References: <CA+AKrqBQ=VG0oVsai+agywDKRgO9cG9AvT6mCTSZxKO3Si5Aiw@xxxxxxxxxxxxxx> <512D3856.5050305@xxxxxxxxxxx> <CA+AKrqC+6nXuCxdY08MBLsjv1fOPJ6=1ruTHsfGqxosQmCi_jQ@xxxxxxxxxxxxxx> <512D49E2.40003@xxxxxxxxxxx> <CA+AKrqCrphO-eKy0n=70O9hmB3mXttOsKmTdfRnPxgJM3_PAkQ@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
On 2/27/13 10:28 AM, Jason Detring wrote:
>             find-502   [000]   207.983594: xfs_da_btree_corrupt: dev 7:0 bno 
> 0x5a4f8 nblks 0x8 hold 1 pincount 0 lock 0 flags DONE|PAGES caller 
> xfs_dir2_leaf_readbuf

Was this on the same image as you sent earlier?

Ok, so this tells us that it was trying to read sector nr. 0x5a4f8 (369912), or 
fsblock 46239

What's really on disk there?

$ xfs_db problemimage.xfs
xfs_db> blockget -n
xfs_db> daddr 369912
xfs_db> blockuse
block 49152 (3/0) type sb
xfs_db> type text
xfs_db> p
000:  58 46 53 42 00 00 10 00 00 00 00 00 00 00 f0 d3  XFSB............

So it really did have a superblock location that it was reading
at that point - the backup SB in the 3rd allocation group, to be exact.
But it shouldn't have been trying to read a superblock at this point
in the code...

Hm, maybe I should have had you enable all xfs tracepoints to get
more info about where we thought we were on disk when we were doing this.
If you used trace-cmd you can do "trace-cmd record -e xfs*" IIRC.
You can do similar echo 1 > /<blah>/xfs*/enable I think for the sysfs route.

Can you identify which directory it was that tripped the above error?

(I still think it sounds like a miscompile, but trying to get more clues)


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