xfs
[Top] [All Lists]

Re: Mounting an xfs partition twice?

To: Eric Sandeen <sandeen@xxxxxxx>, Steve Lord <lord@xxxxxxx>
Subject: Re: Mounting an xfs partition twice?
From: Jim Buzbee <James.Buzbee@xxxxxxxxxxxx>
Date: Thu, 14 Feb 2002 09:54:28 -0700
Cc: XFS List <linux-xfs@xxxxxxxxxxx>
References: <3C6BDFC6.14BE4651@echostar.com> <1013703319.17209.3.camel@stout.americas.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Eric Sandeen wrote:
> 
> On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote:
> 
> > In the corrupted directory, I see several files listed twice, and a
> > simple "ls -l" gives me several  "No such file or directory" errors on
> > other files that were previously in the directory.
> 
> Oh, and for this problem... what flavor of kernel/xfs are you running?

OK, X86, IDE - 2.4.8 Kernel with a number of modifications, compiler  :
egcs 1.1.2 - The xfs patch we applied to the kernel is :

patch-2.4.8-xfs-2001-08-13.bz2

We are pretty much frozen on this kernel right now because of the
difficulty of moving forward our 2.4.8 modifications.

> xfs_repair -n on the filesystem in question might tell us some
> interesting things as well, 

Here's the output :

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
        - agno = 5
        - agno = 6
        - agno = 7
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ...
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.




> but it will be hard to know how the
> filesystem got into this state.  What sorts of interesting things are
> you doing with it?  :)

This condition is unfortunately repeatable (we trashed a number of our
set top boxes...).  For us it occurs during the automated installation
of several compressed tar files - Nothing extraordinary other than the
filesystem is quite busy (we are simultaneously recording and playing
MPEG 2 video from our satellites) - This problem just started occuring -
The only change was a new build of the kernel so that is my current
suspicion...

Jim Buzbee,

Echostar Technologies

> 
> -Eric
> 
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@xxxxxxx   SGI, Inc.


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