xfs
[Top] [All Lists]

Re: XFS trouble (!)

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: XFS trouble (!)
From: Ajay Shekhawat <ajay@xxxxxxxxxxxxxxxxx>
Date: Fri, 29 Nov 2002 22:51:48 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20021130135526.A526752@xxxxxxxxxxxxxxxxxxxxxxxx>
Organization: Center for Document Analysis and Recognition
References: <20021130000059.GA18501@xxxxxxxxxxxxxxxxxxxxxxxx> <20021130135526.A526752@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Sat, Nov 30, 2002 at 01:55:26PM +1100, Nathan Scott wrote:
> Can you send (cut & paste) the exact error message from your
> system logs?  This will show exactly which point in the XFS
> mount code an error is being flagged.  -- thanks.

Nathan,
Here's the snippet from /var/log/messages:
Nov 29 12:44:15 gasque kernel: XFS: nil uuid in log - IRIX style logXFS: failed
to locate log tailXFS: log mount/recovery failedXFS: log mount failedXFS 
mounting filesystem lvm(58,0)

Thats it. No other messages.

I did "xfs_db -r -c uuid /dev/raid/vol", and it printed a non-nil uuid.

> Its strange that xfs_repair is unable to detect any problem
> but the mount is failing - the kernel mount path basically does
> a simplified version of the consistency checks that xfs_repair
> does; so if mount says the SB is bogus, repair should notice
> it too.

Here's the output of 'xfs_repair -n':
[ajay@xxx]$ sudo ./xfs_repair -n /dev/raid/vol
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
        . . . . . . . . . <snipped for brevity>
        - agno = 236
        - agno = 237
        - agno = 238
        - agno = 239
        - 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
        . . . . . . . . . <snipped for brevity>
        - agno = 236
        - agno = 237
        - agno = 238
        - agno = 239
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ...

(it is still running; don't want to interrupt it)

Should I just go ahead and run 'xfs_repair' without the "-n" ?


> cheers.
I need some. :-)


Ajay


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