On 1/27/17 9:43 AM, Eric Sandeen wrote: > I'll keep looking to be sure it's legit. It didn't really make sense > to me either, but ... yup, i'm seeing it. the fsync error doesn't > come through as expected. I'll keep looking into it. Ok finally had time to actually look. generic/108 is doing IO across a stripe and failing one disk; it seems that the reservations have moved the IO pattern in such a way that the fsync'd IO does not hit the disk that failed, so the fsync succeeds. If I bump up the write prior to the fsync frmo 6M to 8M, it fails again as expected. So I'm not quite sure how a 6M write on a 4M stripe device doesn't hit the failing device, but a larger IO makes the test fail again - so I'll chalk this up to a problematic assumption in the test, not a problem with the patch. Thanks, -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
