At 21:42 18-2-2003 -0800, l.a walsh wrote:
Gonna have to break down and setup amanda or tar or something...
Fire corruption by trying to do xfsdump level 0...ug
Hmmm..that's special...last backup where the file was stored 'bin dir',
xfs restore claims it isn't a directory -- just a large 25 meg file.
thatâ??s not nice.
Next in line is to try new xfsdump/restore, but even if they work, its
still bad that xfs dies so easily --
I have no debug output -- it just says found fatal error in file
system and must shutdown the fs. After that, nada...zilch...
no programs can run...not even sync. (ok, so maybe i should copy
my entire root to another disk...but still....*whine whine whine*...
It sounds to me like your filesystem is indeed damaged. I suggest repairing
it with xfs_repair.
You will probably get the filesystem shutdown when using tar as well. The
problem crops up because the moment it tries to read the file it immediatly
triggers a filesystem corruption error state. So it (probably) won't matter
if you would use tar or xfsdump, it would barf anyhow.
Umount the disk, run xfs_repair -n to see what it wants to correct. If it
does not say it wants to put your entire filesystem in lost and found, you
can run xfs_repair normally and it will attempt to fix the problems.
If you are not sure and if the block device is not too large I suggest
dumping it with dd to a file so you have some sort of backup just in case
xfs_repair would turn it into swiss cheese.
dd if=/dev/hda? of=/backup/damaged_fs.bin bs=4096
You can always try running the xfs_repair on this binary file before
running it on your real disk.
Once the filesystem has been repaired you will probably also be able to
normally dump and restoer with xfsdump and or tar.
It might just be your lucky day, if you only knew.