From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@ZenIV.linux.org.uk>, Jan Kara <jack@suse.cz>,
tytso@mit.edu, axboe@kernel.dk, mawilcox@microsoft.com,
ross.zwisler@linux.intel.com, corbet@lwn.net,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it
Date: Thu, 1 Jun 2017 23:25:45 -0600 [thread overview]
Message-ID: <20170602052545.GB5909@linux.intel.com> (raw)
In-Reply-To: <20170531124540.8782-1-jlayton@redhat.com>
On Wed, May 31, 2017 at 08:45:23AM -0400, Jeff Layton wrote:
> v5: don't retrofit old API over the new infrastructure
> add fstype flag to indicate how wb errors are tracked within that fs
> add more function variants that take a errseq_t "since" value
> add second errseq_t to struct file to track metadata wb errors
> convert ext4 and ext2 to use the new APIs
>
> v4: several more cleanup patches
> documentation and kerneldoc comment updates
> fix bugs in gfs2 patches
> make sync_file_range use same error reporting semantics
> bugfixes in buffer.c
> convert nfs to new scheme (maybe bogus, can be dropped)
>
> v3: wb_err_t -> errseq_t conversion
> clean up places that re-set errors after calling filemap_* functions
>
> v2: introduce wb_err_t, use atomics
>
> This is v5 of the patchset to improve how we're tracking and reporting
> errors that occur during pagecache writeback. The main difference in
> this set from the last one is that I've stopped trying to retrofit the
> old error tracking API on top of the new one. This is more work since
> we'll have to touch each fs individually, but should be safer as the
> "since" values used for checking errors will be more deliberate.
>
> There are several situations where the kernel can "lose" errors that
> occur during writeback, such that fsync will return success even
> though it failed to write back some data previously. The basic idea
> here is to have the kernel be more deliberate about the point from
> which errors are checked to ensure that that doesn't happen.
>
> An additional aim of this set is to change the behavior of fsync in
> Linux to report writeback errors on all fds instead of just the first
> one. This allows writers to reliably tell whether their data made it to
> the backing device without having to coordinate fsync calls with other
> writers.
>
> To do this, we add a new typedef: errseq_t. This is a 32-bit value
> that can store an error code, and a sequence number so we can tell
> whether it has changed since we last sampled it. This allows us to
> record errors in the address_space and then report those errors only
> once per file description.
>
> This set just alters block device files, ext4 and the legacy ext2
> driver. If this general approach seems acceptable, then I'll start
> converting other filesystems in follow-on patchsets. I'd also like
> to get this into linux-next as soon as possible to ensure that we're
> banging out any bugs that might be lurking here.
>
> I also have a couple of xfstests for this as well that I'll re-post
> soon.
Can you tell me a baseline that this applies cleanly to, or give me a link to
a tree with these patches already applied? I've tried applying it to v4.11,
linux/master and mmots/master, and so far nothing has worked.
next prev parent reply other threads:[~2017-06-02 5:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 12:45 [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it Jeff Layton
2017-05-31 12:45 ` [PATCH v5 01/17] lib: add errseq_t type and infrastructure for handling it Jeff Layton
2017-05-31 12:45 ` [PATCH v5 02/17] fs: new infrastructure for writeback error handling and reporting Jeff Layton
2017-05-31 12:45 ` [PATCH v5 03/17] mm: tracepoints for writeback error events Jeff Layton
2017-05-31 12:45 ` [PATCH v5 04/17] fs: add a new fstype flag to indicate how writeback errors are tracked Jeff Layton
2017-05-31 12:45 ` [PATCH v5 05/17] Documentation: flesh out the section in vfs.txt on storing and reporting writeback errors Jeff Layton
2017-05-31 12:45 ` [PATCH v5 06/17] fs: adapt sync_file_range to new reporting infrastructure Jeff Layton
2017-05-31 12:45 ` [PATCH v5 07/17] mm: add filemap_fdatawait_range_since and filemap_write_and_wait_range_since Jeff Layton
2017-05-31 12:45 ` [PATCH v5 08/17] dax: set errors in mapping when writeback fails Jeff Layton
2017-06-06 1:01 ` Ross Zwisler
2017-06-06 1:08 ` Jeff Layton
2017-05-31 12:45 ` [PATCH v5 09/17] block: convert to errseq_t based writeback error tracking Jeff Layton
2017-05-31 12:45 ` [PATCH v5 10/17] block: add sync_blockdev_since and sync_filesystem_since Jeff Layton
2017-05-31 12:45 ` [PATCH v5 11/17] fs: add f_md_wb_err field to struct file for tracking metadata errors Jeff Layton
2017-05-31 12:45 ` [PATCH v5 12/17] fs: allow __generic_file_fsync to support both flavors of error reporting Jeff Layton
2017-05-31 12:45 ` [PATCH v5 13/17] jbd2: conditionally handle errors using errseq_t based on FS_WB_ERRSEQ flag Jeff Layton
2017-05-31 12:45 ` [PATCH v5 14/17] ext4: convert to errseq_t based error tracking Jeff Layton
2017-05-31 12:45 ` [PATCH v5 15/17] fs: add a write_one_page_since Jeff Layton
2017-05-31 12:45 ` [PATCH v5 16/17] ext2: convert to errseq_t based writeback error tracking Jeff Layton
2017-05-31 12:45 ` [PATCH v5 17/17] fs: convert ext2 to use write_one_page_since Jeff Layton
2017-05-31 20:27 ` [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it Andrew Morton
2017-05-31 21:31 ` Jeff Layton
2017-05-31 21:37 ` Andrew Morton
2017-05-31 22:01 ` Jeff Layton
2017-06-02 5:25 ` Ross Zwisler [this message]
2017-06-02 10:07 ` Jeff Layton
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=20170602052545.GB5909@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=jack@suse.cz \
--cc=jlayton@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.