> xfs_repair is your only option. Run it and hope for the best.
Ah, it complains about an unflushed log and won't run.
It might be a worthwhile addition to the sfs_repair man
page to mention that "-n" implies "-L".
If it is indeed the case that the *only* code which can replay a log is
in the kernel, that might be worth saying explicitly, too. I'm poking
at xfs_logprint wondering if there's a way to get it to do something
useful.
>> - Can we extract any information about what misbehaved to help the SATA
>> debugging process
> I doubt it.
Well, we can at least conclude that it didn't "fail fast" and freeze at
a particular point in time, right? Because that would have left
consistent metadata.
(OF course, it could been the RAID-10 setup. If I have mirror pairs
A/B and C/D, and the B&C driver got wedged, so the last write went
only to A and D, and on recovery the RAID system synchronized A to B
and C to D, that would leave a half-written log entry. But I'm using
a 256K stripe size, and log entries are 32K, so they shouldn't be split
across stripes....)
Anyway, thanks a lot for your help!
|