From: Jeff Layton <jlayton@kernel.org>
To: Chris Perl <cperl@janestreet.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: Too many ENOSPC errors
Date: Mon, 12 Jun 2023 13:30:45 -0400 [thread overview]
Message-ID: <71b3ff942fdf6f070f6cd59f29e04081d3f94c38.camel@kernel.org> (raw)
In-Reply-To: <cd4e8b16a8c154e6bda38021eef2c0d56badb43c.camel@kernel.org>
On Mon, 2023-06-12 at 11:58 -0400, Jeff Layton wrote:
>
> Got it: I think I see what's happening. filemap_sample_wb_err just calls
> errseq_sample, which does this:
>
> errseq_t errseq_sample(errseq_t *eseq)
> {
> errseq_t old = READ_ONCE(*eseq);
>
> /* If nobody has seen this error yet, then we can be the first. */
> if (!(old & ERRSEQ_SEEN))
> old = 0;
> return old;
> }
>
> Because no one has seen that error yet (ERRSEQ_SEEN is clear), the write
> ends up being the first to see it and it gets back a 0, even though the
> error happened before the sample.
>
> The above behavior is what we want for the sample that we do at open()
> time, but not what's needed for this use-case. We need a new helper that
> samples the value regardless of whether it has already been seen:
>
> errseq_t errseq_peek(errseq_t *eseq)
> {
> return READ_ONCE(*eseq);
> }
>
> ...but we'll also need to fix up errseq_check to handle differences
> between the SEEN bit.
>
> I'll see if I can spin up a patch for that. Stay tuned.
This may not be fixable with the way that NFS is trying to use errseq_t.
The fundamental problem is that we need to mark the errseq_t in the
mapping as SEEN when we sample it, to ensure that a later error is
recorded and not ignored.
But...if the error hasn't been reported yet and we mark it SEEN here,
and then a later error doesn't occur, then a later open won't have its
errseq_t set to 0, and that unseen error could be lost.
It's a bit of a pity: as originally envisioned, the errseq_t mechanism
would provide for this sort of use case, but we added this patch not
long after the original code went in, and it changed those semantics:
b4678df184b3 errseq: Always report a writeback error once
I don't see a good way to do this using the current errseq_t mechanism,
given these competing needs. I'll keep thinking about it though. Maybe
we could add some sort of store and forward mechanism for fsync on NFS?
That could get rather complex though.
Cheers,
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-06-12 17:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 17:05 Too many ENOSPC errors Chris Perl
2023-06-08 20:50 ` Jeff Layton
2023-06-12 14:27 ` Chris Perl
2023-06-12 15:58 ` Jeff Layton
2023-06-12 17:30 ` Jeff Layton [this message]
2023-06-12 17:49 ` Chris Perl
2023-06-12 19:17 ` Jeff Layton
2023-06-12 19:53 ` Trond Myklebust
2023-06-12 20:20 ` Jeff Layton
2023-06-12 21:54 ` Trond Myklebust
2024-05-15 11:59 ` Tee Hao Wei
2023-06-12 19:04 ` Trond Myklebust
2023-06-12 19:21 ` Jeff Layton
2023-06-12 19:59 ` Benjamin Coddington
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=71b3ff942fdf6f070f6cd59f29e04081d3f94c38.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=cperl@janestreet.com \
--cc=linux-nfs@vger.kernel.org \
--cc=willy@infradead.org \
/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