[Top] [All Lists]

Re: XFS trouble (!)

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: XFS trouble (!)
From: Ajay Shekhawat <ajay@xxxxxxxxxxxxxxxxx>
Date: Sat, 30 Nov 2002 13:06:02 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20021130154031.B526752@xxxxxxxxxxxxxxxxxxxxxxxx>
Organization: Center for Document Analysis and Recognition
References: <20021130000059.GA18501@xxxxxxxxxxxxxxxxxxxxxxxx> <20021130135526.A526752@xxxxxxxxxxxxxxxxxxxxxxxx> <20021130035148.GB18501@xxxxxxxxxxxxxxxxxxxxxxxx> <20021130154031.B526752@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Sat, Nov 30, 2002 at 03:40:32PM +1100, Nathan Scott wrote:
> > 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.
> Ah, I see.
> Is this a CVS kernel from sometime in the last week or two?

I downloaded the 2.4.19 kernel, and patched it with the patches at
I thought that would be the best way to go, since 2.4.19 is a "stable"
kernel (well, "was" would be the operative word now that 2.4.20 is out :-/)

> > I did "xfs_db -r -c uuid /dev/raid/vol", and it printed a non-nil uuid.
> Yeah, thats the uuid from the superblock - mount is saying the uuid
> in the log is nil (different place on disk, should be same uuid).

I gave the command
        uuid <uuid printed by xfs_db>
in xfs_db, and it was able to mount the filesystem. Everything _appears_
to be there, though it is difficult to check quickly.

So what are my options now: should I do a 'xfs_check' again?
Should I migrate to the latest CVS branch? It is a production machine,
though, and I'm not sure if the latest bleeding edge release is
the way to go (if something happens, a lot of sharp soon-to-be-bleeding
edges will head my way).

> If this is a kernel which had some of the CVS breakage from the
> last week or so, then you may find changing the uuid using xfs_db
> to be enough to get you up and running again (because xfs_db will
> write both the log uuid and the superblock uuids; and will zero
> the log for you too, which is what we really want here).
> Assuming this is a recent kernel, don't go back to that same one -
> if it is one with this problem it will corrupt the log straight
> away again during recovery.  Get current CVS, its fairly good; or
> better yet get the 1.2 release - its more stable than CVS is just
> now.

There is no "1.2" release; it is still in "pre3" right now.

> Good luck!  (at this stage, looks like you only have corruption in
> the log, so xfs_repair is not going to help too much there - except
> to say there's no corruption elsewhere, which is good).
> cheers.

Thanks for the help, and thanks to SGI for making XFS available.
It is a pretty good filesystem. Of course, it can't be blamed if
the underlying hardware croaks.


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