xfs
[Top] [All Lists]

Re: FYI: xfs problems in Fedora 8 updates

To: David Chinner <dgc@xxxxxxx>
Subject: Re: FYI: xfs problems in Fedora 8 updates
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 28 Mar 2008 07:22:12 -0500
Cc: markgw@xxxxxxx, xfs-oss <xfs@xxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>
In-reply-to: <20080328051456.GH108924158@xxxxxxx>
References: <47E3CE92.20803@xxxxxxxxxxx> <47E8687A.90306@xxxxxxx> <47EC734D.2020304@xxxxxxxxxxx> <20080328051456.GH108924158@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
David Chinner wrote:
> On Thu, Mar 27, 2008 at 11:25:49PM -0500, Eric Sandeen wrote:
>> Mark Goodwin wrote:
>>> Eric Sandeen wrote:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=437968
>>>>  Bugzilla Bug 437968: Corrupt xfs root filesystem with kernel
>>>> kernel-2.6.24.3-xx
>>>>
>>>> Just to give the sgi guys a heads up, 2 people have seen this now.
>>>>
>>>> I know it's a distro kernel but fedora is generally reasonably close to
>>>> upstream.
>>>>
>>>> I'm looking into it but just wanted to put this on the list, too.
>>> Hi Eric, have you identified this as any particular known problem?
>>>
>>> Cheers
>> >From a testcase and some git bisection, looks like this mod broke it
>> somehow, but not sure how yet:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2bdf7cd0baa67608ada1517a281af359faf4c58c
>>
>> [XFS] superblock endianess annotations
> 
> Uh, what? Functionally that's a no-op....

well, it's supposed to be... but I guess that's why they call it a bug?
 :)  really and truly, that's where bisect landed, and I tested a few
times with and without the patch and it seems to confirm.

> Is this only showing up on attr=2 filesystems?

a little hard to say since it has the 64-bit features2 padding problem...

but:

[root@bear-05 test]# xfs_db -c version testfs
versionnum [0xb094+0x8] = V4,ATTR,ALIGN,DIRV2,EXTFLG,MOREBITS,ATTR2

I can try later on non-attr2... this fs was originally created by the
installer.

> And it looks like it was a directory inode judging by all the
> disconnected inodes. Looks like a corrupted directory extent btree
> from this.  Can you run `xfs_db -r -c "inode 17627699" -c p <dev>`
> so we can confirm this?

sorry, meant to do that:

# xfs_db -r -c "inode 17627699" -c p testfs
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 3 (btree)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.flushiter = 2
core.atime.sec = Wed Jan  9 12:14:05 2008
core.atime.nsec = 000000000
core.mtime.sec = Fri Mar 28 07:16:54 2008
core.mtime.nsec = 590127668
core.ctime.sec = Fri Mar 28 07:16:54 2008
core.ctime.nsec = 590127668
core.size = 81920
core.nblocks = 30
core.extsize = 0
core.nextents = 23
core.naextents = 1
core.forkoff = 15
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 0
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:0
a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1103697,1,0]

-Eric


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