linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: commit b4678df184b causing xfstests regressions
Date: Sat, 19 May 2018 09:09:46 -0400	[thread overview]
Message-ID: <630faadb74f608aa5a42649b81657e8b62d46bc3.camel@kernel.org> (raw)
In-Reply-To: <20180518225037.GA26206@thunk.org>

On Fri, 2018-05-18 at 18:50 -0400, Theodore Y. Ts'o wrote:
> Hi Matthew,
> 
> Commit b4678df184b: "errseq: Always report a writeback error once"
> appears to be causing xfstests regressions.  For ext4, running
> "gce-xfstests -c 4k -g auto" will result in reliable shared/298
> failures which go away if I revert b4678df184b.
> 
> Darrick has also reported occasional generic/047 failures, which I
> have seen at least once as well.  I believe two are linked, because
> after instrumenting mke2fs in shared/298, the failure is happening
> after creating a new 300 MB file:
> 
> dd if=/dev/zero of=$img_file bs=1M count=300 &> /dev/null
> 
> creating a new loop device
> 
> loop_dev=$(_create_loop_device $img_file)
> 
> ... and then run mke2fs on that loop device.
> 
> The instrumentation of mke2fs shows that the first fsync() on
> /dev/loop0 (in lib/ext2fs/closefs.c) which is failing with EIO.
> 
> I haven't had a chance to really drill down on it, but I think what is
> going on is there is some former test which exercises an error path
> (using dm_error, or some such), and somehow the errseq_t for the loop
> device isn't getting reset, or the inode for the underlying backing
> file, had an unitialized errseq_t.
> 
> Can you take a closer look at this?
> 
> Thanks,
> 
> 					- Ted
> 

Thanks Ted. I'm not that familiar with the loopdev code, but after
giving it a quick look, I suspect that you're correct. We probably need
to do something like reset the loop device's bd_inode->i_mapping->wb_err 
back to zero when we detach the file that backs it.

I wonder if we could roll a test that would do:

create a scratch fs on a dm-error dev with a file on it
set up a loop device on that file
have the backing device of the scratch file throw errors
write to the device
detach loop device
clear dm-error condition
delete file and recreate it
attach same loop device to new file
fsync loop device

My suspicion is that that last fsync would throw an error now and it
wouldn't have before.
-- 
Jeff Layton <jlayton@kernel.org>

  parent reply	other threads:[~2018-05-19 13:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 22:50 Theodore Y. Ts'o
2018-05-19  2:17 ` Matthew Wilcox
2018-05-19 13:09 ` Jeff Layton [this message]
2018-05-19 15:25   ` Darrick J. Wong
2018-05-19 15:27   ` [PATCH] fs: clear writeback errors in inode_init_always Darrick J. Wong
2018-05-19 15:36     ` Matthew Wilcox
2018-05-21 17:54       ` Darrick J. Wong
2018-05-22 10:30         ` Jeff Layton
2018-05-22 22:09           ` Dave Chinner
2018-05-23 10:56             ` Jeff Layton
2018-05-24  3:59               ` Dave Chinner
2018-05-19 23:19     ` Theodore Y. Ts'o
2018-05-20 11:45       ` Jeff Layton
2018-05-20 12:58         ` Matthew Wilcox
2018-05-20 13:18           ` Jeff Layton
2018-05-20 16:29           ` Theodore Y. Ts'o
2018-05-20 19:20             ` Matthew Wilcox
2018-05-20 19:41               ` Theodore Y. Ts'o
2018-05-21 11:20                 ` Jeff Layton
2018-05-21 14:43                   ` Theodore Y. Ts'o
2018-05-20 17:57         ` Theodore Y. Ts'o
2018-05-22  4:06     ` [PATCH v2] " Darrick J. Wong
2018-05-22 10:14       ` Jeff Layton
2018-05-22 12:14       ` Brian Foster
2018-05-22 14:37         ` Darrick J. Wong
2018-05-22 16:43     ` [PATCH v3] " Darrick J. Wong
2018-05-22 18:40       ` Brian Foster
2018-05-22 18:47         ` Darrick J. Wong
2018-05-22 22:05       ` Dave Chinner
2018-05-23  3:00         ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=630faadb74f608aa5a42649b81657e8b62d46bc3.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    --subject='Re: commit b4678df184b causing xfstests regressions' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).