From: NeilBrown <neilb@suse.com>
To: Jeff Layton <jlayton@redhat.com>,
viro@zeniv.linux.org.uk, konishi.ryusuke@lab.ntt.co.jp
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-nilfs@vger.kernel.org
Subject: Re: [PATCH 0/3] mm/fs: get PG_error out of the writeback reporting business
Date: Mon, 06 Mar 2017 14:06:11 +1100 [thread overview]
Message-ID: <871subkst8.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170305133535.6516-1-jlayton@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
On Sun, Mar 05 2017, Jeff Layton wrote:
> I recently did some work to wire up -ENOSPC handling in ceph, and found
> I could get back -EIO errors in some cases when I should have instead
> gotten -ENOSPC. The problem was that the ceph writeback code would set
> PG_error on a writeback error, and that error would clobber the mapping
> error.
>
> While I fixed that problem by simply not setting that bit on errors,
> that led me down a rabbit hole of looking at how PG_error is being
> handled in the kernel.
Speaking of rabbit holes... I thought to wonder how IO error propagate
up from NFS.
It doesn't use SetPageError or mapping_set_error() for files (except in
one case that looks a bit odd).
It has an "nfs_open_context" and store the latest error in ctx->error.
So when you get around to documenting how this is supposed to work, it
would be worth while describing the required observable behaviour, and
note that while filesystems can use mapping_set_error() to achieve this,
they don't have to.
I notice that
drivers/staging/lustre/lustre/llite/rw.c
fs/afs/write.c
fs/btrfs/extent_io.c
fs/cifs/file.c
fs/jffs2/file.c
fs/jfs/jfs_metapage.c
fs/ntfs/aops.c
(and possible others) all have SetPageError() calls that seem to be
in response to a write error to a file, but don't appear to have
matching mapping_set_error() calls. Did you look at these? Did I miss
something?
Thanks,
NeilBrown
>
> This patch series is a few fixes for things that I 100% noticed by
> inspection. I don't have a great way to test these since they involve
> error handling. I can certainly doctor up a kernel to inject errors
> in this code and test by hand however if these look plausible up front.
>
> Jeff Layton (3):
> nilfs2: set the mapping error when calling SetPageError on writeback
> mm: don't TestClearPageError in __filemap_fdatawait_range
> mm: set mapping error when launder_pages fails
>
> fs/nilfs2/segment.c | 1 +
> mm/filemap.c | 19 ++++---------------
> mm/truncate.c | 6 +++++-
> 3 files changed, 10 insertions(+), 16 deletions(-)
>
> --
> 2.9.3
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-03-06 3:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 13:35 [PATCH 0/3] mm/fs: get PG_error out of the writeback reporting business Jeff Layton
2017-03-05 13:35 ` Jeff Layton
2017-03-05 13:35 ` [PATCH 1/3] nilfs2: set the mapping error when calling SetPageError on writeback Jeff Layton
2017-03-05 13:35 ` Jeff Layton
2017-03-07 13:46 ` Ryusuke Konishi
2017-03-07 13:46 ` Ryusuke Konishi
2017-03-05 13:35 ` [PATCH 2/3] mm: don't TestClearPageError in __filemap_fdatawait_range Jeff Layton
2017-03-05 13:35 ` Jeff Layton
2017-03-05 13:35 ` [PATCH 3/3] mm: set mapping error when launder_pages fails Jeff Layton
2017-03-05 13:35 ` Jeff Layton
2017-03-05 14:40 ` [PATCH 0/3] mm/fs: get PG_error out of the writeback reporting business Jeff Layton
2017-03-05 14:40 ` Jeff Layton
2017-03-06 23:08 ` Ross Zwisler
2017-03-06 23:08 ` Ross Zwisler
2017-03-07 10:26 ` Jan Kara
2017-03-07 10:26 ` Jan Kara
2017-03-07 14:03 ` Jeff Layton
2017-03-07 14:03 ` Jeff Layton
2017-03-07 15:59 ` Ross Zwisler
2017-03-07 15:59 ` Ross Zwisler
2017-03-07 16:17 ` Jan Kara
2017-03-07 16:17 ` Jan Kara
2017-03-09 2:57 ` Theodore Ts'o
2017-03-09 2:57 ` Theodore Ts'o
2017-03-09 9:04 ` Jan Kara
2017-03-09 9:04 ` Jan Kara
2017-03-09 10:47 ` Jeff Layton
2017-03-09 10:47 ` Jeff Layton
2017-03-09 11:02 ` Jan Kara
2017-03-09 11:02 ` Jan Kara
2017-03-09 12:43 ` Jeff Layton
2017-03-09 12:43 ` Jeff Layton
[not found] ` <1489063392.2791.8.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-09 13:22 ` Brian Foster
2017-03-09 13:22 ` Brian Foster
2017-03-09 13:22 ` Brian Foster
2017-03-09 14:21 ` Theodore Ts'o
2017-03-09 14:21 ` Theodore Ts'o
2017-03-15 5:07 ` [RFC PATCH] mm: retry writepages() on ENOMEM when doing an data integrity writeback Theodore Ts'o
2017-03-15 11:59 ` Jan Kara
2017-03-15 14:09 ` Theodore Ts'o
2017-03-15 14:09 ` Theodore Ts'o
2017-03-15 13:03 ` Michal Hocko
2017-03-16 10:18 ` Tetsuo Handa
2017-03-06 3:06 ` NeilBrown [this message]
[not found] ` <871subkst8.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-03-06 11:43 ` [PATCH 0/3] mm/fs: get PG_error out of the writeback reporting business Jeff Layton
2017-03-06 11:43 ` Jeff Layton
2017-03-06 11:43 ` 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=871subkst8.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=jlayton@redhat.com \
--cc=konishi.ryusuke@lab.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nilfs@vger.kernel.org \
--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.