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
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).
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.