xfs
[Top] [All Lists]

Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid

To: linux@xxxxxxxxxxx
Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid
From: Eric Sandeen <sandeen@xxxxxxx>
Date: Tue, 01 Nov 2005 21:45:39 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20051102011753.28539.qmail@science.horizon.com>
References: <20051102011753.28539.qmail@science.horizon.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
linux@xxxxxxxxxxx wrote:
Well, xfs does assume that if the underlying IO layers tell it that
something is written, that it is in fact written.  Depending on the level
of flakiness in your SATA driver, it looks quite possible that you have
encountered a SATA bug, not an xfs bug.


I assure you, I don't expect perfection in the face of such
flakiness, but it did seem a little bit less than robust.

If the underlying layers tell XFS that data is safe, it is not XFS's fault when it's not there later, and in fact there is nothing that XFS or any other journaling filesystem can do about it... things are journaled only until they are safe on disk, as reported by the IO subsystems.


Mostly, I'm wondering:
- Can we extract any information about what misbehaved to help the SATA
  debugging process

I doubt it.

- Is running xfs_repair the best thing to do?  Are all of those error
  messages reasonably harmless?  I don't know what's "normal" in
  xfs_repair output the way that I know that complaints about dtime,
  too many blocks allocated, and bitmap inconsistencies are basically
  harmless in e2fsck output, and I only need to worry about other
  messages.

xfs_repair is your only option. Run it and hope for the best.

-Eric


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