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
|