Hi Peter,
FYI
Just a couple of things in case you weren't aware.
Often it is simplest to save the log using the -C option to a file.
-C filename
Copy the log from the filesystem to the file filename.
The log itself is not printed.
The log can then be analysed in various ways later.
Running logprint in operation mode (the default mode without options)
(non-transaction mode without -t)
is really pretty useless without the -s option.
If you use the -s option then one needs to know where to seek to
(you can use -t to find the head/tail or -d to see where log records start).
The problem here is that if you do logprint
like this (no options) then it will start at offset zero and will invariably
have
trouble decoding if the log has wrapped around (the general case) as
you'll start in the middle of a record.
So the -t option is often a more interesting starting point as it
will operate more like the file system recovery does, finding the head and tail,
and processing from the tail to the head of the log.
If you want to save the filesystem away for possible metadata debugging later,
then xfs_metadump is your friend.
Cheers,
Tim.
KELEMEN Peter wrote:
* Lachlan Mcilroy (lachlan@xxxxxxx) [20071203 14:24]:
Lachlan,
Okay, sounds like it might be a corrupt log.
Yep.
Can you run xfs_logprint on the device or saved log?
Sure.
http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2
It aborted though, with the following message:
xfs_logprint: unknown log operation type (343b)
Bad data in log
Also give xfs_logprint -t -i a go.
http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2
You've saved the log into a file? You can get the filesystem
mounted again by deleting the log with xfs_repair -L <dev>.
You'll probably need to run xfs_repair over the filesystem to be
safe.
I conserved this filesystem away for further analysis, I'm not
sure how helpful it can be.
Thanks,
Peter
|