On Sat, Aug 20, 2016 at 10:44:01PM +0800, Eryu Guan wrote: > Hi Dave, > > Can you please pull the fstests update from the location below? This is a > normal update, which contains new generic and XFS tests and other fixes. > > Thanks, > Eryu > > The following changes since commit c760a54061d26890be3929e4c6659bf3dc9e0c6a: > > src/t_immutable: allow EPERM on immutable inode (2016-08-12 11:17:34 +0800) > > are available in the git repository at: > > https://github.com/guaneryu/xfstests.git for-dave > > for you to fetch changes up to 3c75489a57518745598e239ffeec2af64400f185: > > common/rc: improve _require_metadata_journaling() for ext4 (2016-08-20 00:54:28 +0800) > > ---------------------------------------------------------------- > > fstests: update on 2016-08-20 > > This update contains: > o New tests for generic and XFS > o Miscellaneous small fixes > > ---------------------------------------------------------------- > Brian Foster (1): > generic: shutdown fs after log recovery Hi Eryu, I just pulled this all in and got an unexpected surprise - this new test killed all of my test machines. From your description ("normal update") I didn't expect to see something like this occur - I pulled it, confirmed commits match, then pushed it to my test machines and started a test cycle. I expected to see it complete without any significant problems. The issue here is that this new test exercises a crash case and does not have fixes that are upstream yet - we have review backlog that has piled up while 4.8-rc1 regressions are being dealt with and getting the xfsprogs rmap support reviewed and merged. Upstream can only move as fast as review bandwidth will allow, and so sometimes things don't get merged as quickly as we'd all like. As such, can you try to hold off merging new tests that crash or hang systems until the bug fixes have been committed in the upstream repositories? This won't affect reviewers or testers (they grab the test in themselves to exercise the problem), but for everyone else merging it will just be a nuisance because there's nothing they can do to make the test pass (excluding it is the only solution). In future, maybe it would be a good idea to ask the patch submitter to tell you when the fix for a dangerous test like this has been merged? That way you can and use that to determine when you push it out for everyone? If it's just a pass/fail test it really doesn't matter, but dangerous tests need to be handled a bit more carefully. For now, I'm going to hold off pushing this update out so other people don't have to work around this issue whilst we clear out the upstream patch backlog. Hopefully that won't take too long. 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
