Oliver Joa wrote:
eason or another, xfs has detected a corrupted on-disk inode format which it cannot recognize, and shuts down.
---- Oh, one other thing that may not apply in your case, but may. Does your SATA disk support write caching? Does it support something called a barrier function? (not real clear on all the ways this can go wrong, but I believe barriers are supposed to guarantee previous data has been fixed on disk (not in write cache). If the SATA controller issues a reset, it may very well purge the write cache. Theoretically, I can think of a _possibility_, that the reset disk would purge the write cache and the barrier indicator would tell xfs to resume writing. From a recent thread on the xfs list, it would appear this could be a "bad" thing (like crossing the streams ala "ghostbusters", but in a data-integrity context).
Just a "shot in the dark" -- absent knowing anything specific about your hardware or situation... If that's the case, you might want to turn off write caching, since when xfs thinks "barriers" work, it turns off some "protection", that can enable some significant speedup in some situations. As an aside, some disks, I gather, may "claim" to support barriers, but really don't. Xfs tries to verify the barrier claim, but I don't know that a reset issued to the disk will have deterministic behavior across all manufacturer's disks. A bunch of "coulds" and "maybe's", but just thinking off top of head... Linda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
