xfs
[Top] [All Lists]

Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid

To: sandeen@xxxxxxx
Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid
From: linux@xxxxxxxxxxx
Date: 2 Nov 2005 14:07:44 -0500
Cc: linux@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: <43683663.9030807@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
> 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!


<Prev in Thread] Current Thread [Next in Thread>