Hmmm....
xfsdump seems to be running now ....
went down to single user unmounted all FS's, but couldn't
kill the test program running on /tmp, so to be safe, rebooted
into single user...ran xfs_repair ...found about 15
disconnected inodes dating back to around the time I upgraded
from SuSE 8.0 -> 8.1. Could be coincidental, but about 7
of the files were also bits of YAST2 output.
Rebooted second time -- back up and doing level 0 dumps...
So...one of those disconnected inodes was the one mentioned
in death message -- that xfsdump died on -- #1590.
So couple of questions/observations...
Here I had a file system (all the recovered files were
dated between 9-sep-2002 -> 12-sep-2002) that, except for
being 'undumpable' (not a great thing, mind you) seemed to
function just fine as a regular good 'ol file system. Recovered
fine on unexpected crashes...etc.
So 1) Maybe xfsdump or the 'getbulkstat' operation should
be slightly more fault tolerant? Seems like shutting down
the file system wasn't the most informative action to take.
Perhaps more important (2): it would be REAL helpful if
either xfs_repair or xfs_check would return an indication
that there is a problem on a mounted filesystem
(not necessarily correct the problem, though that would be ideal),
but at least give me a way of determining that there is a
problem so I can know that I should do a repair (hopefully before
the system is taken down by an xfsdump).
Mucho Bueno Thanks....though I'm still not sure how I got
to where I was at...
> With debug enabled, basically all bets are off and we're actively
> trying to crash the system - since your fs had known corruption,
> this was always going to happen. Guess I should have spelled that
> out a bit more... ;)
---
Not a prob....I always build with kdb enabled...:-)
linda
|