Re: [PATCH 0/2 V4] Resubmit items failed during writeback

[Brian Foster <bfoster@redhat.com>]

On Fri, Jun 16, 2017 at 12:54:43PM +0200, Carlos Maiolino wrote:
> Hi,
> 
> there goes a new version of this patchset based on previous reviews on V3.
> 
> Changelogs added separated to each patch.
> 

Hi Carlos,

I pointed out the last things that I'm aware of that I think need to be
fixed in this series (along with a few nits here and there). That said,
it's already been pointed out that we probably want an xfstests test
case to go along with this before it would be merged. Is that something
you are still planning on?

I'd actually like to take this a bit farther than a regression test and
see if we can improve our ability to test the error handling code in
general. What do you (or anybody else..) think about including a patch
in this series that introduces the ability to inject metadata writeback
errors on DEBUG kernels? For example, consider something that just sets
b_error at the top of xfs_buf_iodone_callbacks() based on a random value
and configurable error frequency. This could use XFS_TEST_ERROR() or
something like a new DEBUG sysfs attribute in the error configuration
(see log_badcrc_factor for a similar example).

This would facilitate longer running tests where iodone callback errors
occur randomly and transiently and we can thus actually exercise the
error handling and recovery code. I'd love to run some fsstress testing,
for example, as I'm hoping that would help wring out any further issues
that could be lurking (particularly with the tricky xfs_iflush_done()
logic and whatnot). If implemented generally enough, that could also be
reused for a more simple xfstests regression test for the original
problem (e.g., mount fs, set error frequency = 100%, modify an inode,
set error frequency = 0, umount), albeit it would require debug mode.
Thoughts?

Brian

> 
> -- 
> 2.9.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html