xfs
[Top] [All Lists]

Re: FYI: xfs problems in Fedora 8 updates

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: FYI: xfs problems in Fedora 8 updates
From: David Chinner <dgc@xxxxxxx>
Date: Fri, 28 Mar 2008 16:14:56 +1100
Cc: markgw@xxxxxxx, xfs-oss <xfs@xxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>
In-reply-to: <47EC734D.2020304@sandeen.net>
References: <47E3CE92.20803@sandeen.net> <47E8687A.90306@sgi.com> <47EC734D.2020304@sandeen.net>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
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....

Is this only showing up on attr=2 filesystems?

> p.s. testcase was updating "foomatic" in a fresh F8 root on my test
> box... w/ this mod in place, subsequent xfs_repair is very unhappy:
> 
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - scan filesystem freespace and inode maps...
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan (but don't clear) agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
>         - agno = 4
> 41802940: Badness in key lookup (length)
> bp=(bno 0, len 512 bytes) key=(bno 0, len 4096 bytes)
> bad magic # 0x58465342 in inode 17627699 (data fork) bmbt block 0
> bad data fork in inode 17627699
> would have cleared inode 17627699

That's an inode bmbt block pointer that points to block zero. That's
why it read the superblock instead of a btree block.

> bad magic # 0x58465342 in inode 17627699 (data fork) bmbt block 0
> bad data fork in inode 17627699
> would have cleared inode 17627699
> entry "printer" in shortform directory 29824865 references free inode 17627699
> would have junked entry "printer" in directory inode 29824865
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>         - traversing filesystem ...
> entry "printer" in shortform directory inode 29824865 points to free
> inode 17627699would junk entry
>         - traversal finished ...
>         - moving disconnected inodes to lost+found ...
> disconnected inode 17627698, would move to lost+found
> disconnected inode 17627700, would move to lost+found
> disconnected inode 17627701, would move to lost+found
.....

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?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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