Ricky Beam wrote:
On Sat, 29 May 2004, Steve Lord wrote:
You have turned on XFS debug, which is really a developer option. It
looks like you have a corrupt journal though. A non debug kernel may
still refuse to mount it and you would need to run xfs_repair from
a rescue disk in that case.
Unless xfs_repair has been changed recently, all it will be able to do it
delete (zero) the journal. If it detects metadata in the journal, it'll
stop and tell you mount the filesystem to replay the journal. Personally,
I think that's sorta stupid... if I could mount the fs, I wouldn't be
running xfs_repair. (I've had the journal become spooge on a sparc64
box a few times.)
Yes, xfs_repair will not replay a log, and if it finds dirty metadata in
the log it wants you to replay it via mount. Having xfs_repair able to
replay the log would be handy, but if mount cannot replay it, then
repair will not either. xfs_repair -L bypasses this check and resets
the log. Following that it does a complete consistancy check and
fixup of metadata - it does a good job in most cases. Note that it
deletes lost+found, and if you had files in there, they would be
disconnected and get put back in lost+found again.
The whole reason for -L was customers who automatically ran xfs_repair
after a crash, and hence threw away anything which was in the log. So
it is more of a stop and think what you are doing option.
There should be a way to instruct the kernel's rootfs mount to not look
at the log. I don't know if one can pass any generic mount options at
boot. ("ro"/"rw" and rootfs type, but I don't know of any others.) This
would be handy for more than just xfs, btw.
You can mount norecovery,ro - but no guarantees that it will stay up
long. See Documentation/filesystems/xfs.txt for a list of xfs mount