From: "Tee Hao Wei" <angelsl@in04.sg>
To: "Jeff Layton" <jlayton@kernel.org>,
"Trond Myklebust" <trondmy@hammerspace.com>,
cperl@janestreet.com
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>
Subject: Re: Too many ENOSPC errors
Date: Wed, 15 May 2024 19:59:22 +0800 [thread overview]
Message-ID: <21fcfc6e-4d34-43bc-8bdb-63a5cd0e0c9c@app.fastmail.com> (raw)
In-Reply-To: <77344fe208d76fa98ba24d79f2246e34ae20b543.camel@kernel.org>
Hi,
On Tue, 13 Jun 2023, at 04:20, Jeff Layton wrote:
> The point here would be to bring NFS more into line with how other
> filesystems behave. As Chris pointed out, other filesystems don't report
> an error on a new write() just because there was an earlier, unseen
> writeback error on the same inode.
>
> I think we can achieve this by carving out another flag bit from the
> errseq_t counter. I'm building and testing a patch now, and I'll post it
> once I'm convinced it's sane.
Just wondering if anything has happened regarding this issue. I saw
"[RFC PATCH] errseq_t: split the ERRSEQ_SEEN flag into two" on the list
but that didn't seem to get any attention.
The current behaviour is really quite surprising because if you have the
following sequence:
1. quota hit or remote disk runs out of space
2. write() returns 0
3. close() [1]
4. space freed
5. write() returns ENOSPC
and then read the file, you'll see the contents from the write in (5)
and *not* the write in (2), even though the write in (5) is the one that
returned an error.
[1]: this returns ENOSPC too, but it seems like we're assuming applications
don't check the result of close()
--
Hao Wei
next prev parent reply other threads:[~2024-05-15 11:58 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
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 [this message]
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=21fcfc6e-4d34-43bc-8bdb-63a5cd0e0c9c@app.fastmail.com \
--to=angelsl@in04.sg \
--cc=cperl@janestreet.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).