On Tue, Oct 29, 2019 at 12:49:24PM +0530, Ritesh Harjani wrote: > > So it looks like these failed tests does not seem to be because of this > patch series. But these are broken in general for at least 1K blocksize. Agreed, I failed to add them to the exclude list for diread_nolock_1k. Thanks for pointing that out! After looking through these patches, it looks good. So, I've landed this series on the ext4 git tree. There are some potential conflicts with Matthew's DIO using imap patch set. I tried resolving them in the obvious way (see the tt/mb-dio branch[1] on ext4.git), and unfortunately, there is a flaky test failure with generic/270 --- 2 times out 30 runs of generic/270, the file system is left inconsistent, with problems found in the block allocation bitmap. [1] https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=tt/mb-dio I've verified that generic/270 isn't a problem on -rc3, and it's not a problem with just your patch series. So, it's almost certain it's because I screwed up the merge. I applied each of Matthew's patch one at a time, and conflict was in changes in ext4_end_io_dio, which is dropped in Matthew's patch. It wasn't obvious though where the dioread-nolock-1k change should be applied in Matthew's patch series. Could you take a look? Thanks!! > Also as an FYI, it seems generic/388 is also broken for blocksize < > pagesize for both platforms. So I will be planning to look into these > failures (generic/273 generic/388 generic/476) in parallel. generic/388 is broken in a flaky fashion on all of the tests. That's a shutdown test, and it's a known issue, having to do with how we forcibly shut down the journalling machinery not being quite right. Since unclean power off and/or dropped fibre channel/iSCSI case is handled correctly, this hasn't been high on the priority list to track down and fix. > Do you think we can work on these failing tests separately, since it does > not look to be failing because of these patches and go ahead in > reviewing this current patch series? Oh, I agree, those failures are pre-existing test failures, and so it shouldn't and doens't block this series. Thanks for your work on this feature! - Ted
