linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Mayhew <smayhew@redhat.com>
To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 0/2] nfs: two writeback error reporting fixes
Date: Fri, 31 Jul 2020 13:46:12 -0400	[thread overview]
Message-ID: <20200731174614.1299346-1-smayhew@redhat.com> (raw)

These fixes fix two regressions reported by Red Hat QE.  This first
issue reported was that writing a file larger than the available space
would result in a client hang instead of returning -ENOSPC.  The second
issue reported was that the client was returning -EIO instead of -EDQUOT
when a quota is exceeded.

On further investigation, I found that in the first issue the client
wasn't really hung.  Instead it was performing all of the requested
writes before it would eventually return -ENOSPC.  The dd command was
writing 400TB, which would have taken a few weeks to complete.
Adjusting the 'bs' and 'count' arguments so that the resulting file
would be much smaller (but still enough to fill up the space on the NFS
server) showed that the dd command would indeed complete with -ENOSPC.
But on older kernels even the 400TB dd would return -ENOSPC quickly.

In the second issue, I found that adding 'conv=fsync' would make the dd
command return -EDQUOT.  So what was happening with the original
command was that it was doing a close() without first calling fsync()
and the close() was returning -EIO.

I bisected both of these down to commit aded8d7b54f2 ("NFS: Don't
inadvertently clear writeback errors").  HOWEVER, as a test I reverted
that commit and it wasn't sufficient to bring back the old behavior.  I
turns out that was due to commit 6fbda89b257f ("NFS: Replace custom
error reporting mechanism with generic one").  This is why I listed the
second commit in the 'Fixes:' tag of both of my patches.

The first patch fixes the -EDQUOT issue and the second one fixes the
-ENOSPC issue.

-Scott

Scott Mayhew (2):
  nfs: ensure correct writeback errors are returned on close()
  nfs: nfs_file_write() should check for writeback errors

 fs/nfs/file.c     | 15 +++++++++++----
 fs/nfs/nfs4file.c |  3 ++-
 2 files changed, 13 insertions(+), 5 deletions(-)

-- 
2.25.4


             reply	other threads:[~2020-07-31 17:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 17:46 Scott Mayhew [this message]
2020-07-31 17:46 ` [PATCH 1/2] nfs: ensure correct writeback errors are returned on close() Scott Mayhew
2020-07-31 19:16   ` Trond Myklebust
2020-07-31 19:43     ` Scott Mayhew
2020-07-31 19:49       ` Trond Myklebust
2020-07-31 17:46 ` [PATCH 2/2] nfs: nfs_file_write() should check for writeback errors Scott Mayhew

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=20200731174614.1299346-1-smayhew@redhat.com \
    --to=smayhew@redhat.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.com \
    /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 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).