Ragnar Kjxrstad wrote:
On Tue, May 07, 2002 at 10:58:10AM -0500, Eric Sandeen wrote:
Hm, looks like log code error handling in general still needs some
scrutiny... I have to work my way out from under some internal
deadlines, and then I can start to look at this.
Thanks.
Is there something we can test in the meantime to get our filesystem
back? I was thinking of commenting out the zero_log() part of xfs_repair
to get it to run the rest of the process. Is that safe? Will the
filesystem mount afterwards?
Or is there a different (better) way to get the repair going?
Also; if we can work-around this problem, is there some data we should
extract from the filesystem first if you wish to debug the problem
later? We already sent the superblock, but if there are other data that
might be useful we'll copy that off before doing anything to the
filesystem.
Can you run xfs_check on the filesystem and see what that reports? It
ignores the log,
so there is no problem there.
Careful use of dd into the block device can do this. Using the superblock
info which is in filesystem blocks.
You need to do this:
xfs_db -r /dev/xxx
sb 0
p
and find the logstart field. Then convert it to a disk address using xfs_db
convert fsblock xxxxx daddr
where xxxx is the value for logstart
This will put it in 512 byte blocks, note that a regular divide
operation will
not help as this is not such a simple mapping.
You can then use dd to write some zeros into this location, you probably
want to do it for logblocks blocks, this value is in 4K units, just multiply
by 8 to get 512 byte units.
To be doubly safe, dd this portion of the device out to a file before
zeroing it.
You can then use xfs_repair on the filesystem to hopefully fix it up,
it usually does a good job.
Steve
|