On Fri, Apr 13, 2018 at 11:42:10PM +1000, Dave Chinner wrote: > On Fri, Apr 13, 2018 at 12:36:12PM +0800, Eryu Guan wrote: > > > > But this issue looks like a bug in xfsprogs to me, not a missing feature > > > > in xfsprogs on RHEL7, so I tend to fail the test instead of adding a new > > > > _require rule & _notrun the test. And in this case, IMHO, I don't think > > > > it's necessary to do any update to the test, just leave the test as it > > > > is and file a new bug in Red Hat bugzilla. > > > > > > ... this isn't a RHEL specific issue - it's an xfsprogs version > > > issue. i.e. any older distro that has a binary with a broken > > > "write array" command will fail this test. None of them are going to > > > get updated xfsprogs packages, so like having an old mkfs.xfs > > > binary, this test should run conditionally on having a version of > > > xfs_db that actually works correctly.... > > > > But I still think it's a pure bug in xfsprogs, not xfsprogs version > > issue nor a behavior change in xfsprogs, as we did support "write via > > array indexing", just that it was broken in a certain case, and commit > > 4222d000ed3b fixed that bug. We should expose bugs by letting the test > > fail, not paper over it by _notrun the test. > > Yes, it's a bug in xfsprogs. But it's a bug in a diagnostic > utility that is only used by test infrastructure and XFS > developers. OK, I got your point now, it's a bug in a diagnostic tool that is only used by XFS developers as a test infrastructure, so we can treat it as a infrastructure dependency as all other _require rules. I think that makes sense in this case. Thanks for the explanation! yang xu, would you mind sending a v2 patch as Dave suggested? Thanks! Eryu > > Yes, it's ialso fixed in recent version of xfsprogs, but you know > very well that we test distros that have ancient xfsprogs and will > never have this issue fixed in them. We use detectiona nd notrun to > avoid tests they should not run all the time, and I don't see how > this is any different. > > I really don't understand why you are pushing back on this - why > should this specific infrastructure deficiency cause test failures, > when all the existing infrastructure support checks cause tests to > notrun rather than fail? > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html