Received-SPF: pass (google.com: domain of linux-nfs+bounces-3259-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Feedback-ID: i8ba9497a:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-455-g0aad06e44-fm-20240509.001-g0aad06e4
Precedence: bulk
MIME-Version: 1.0
Message-Id: <21fcfc6e-4d34-43bc-8bdb-63a5cd0e0c9c@app.fastmail.com>
In-Reply-To: <77344fe208d76fa98ba24d79f2246e34ae20b543.camel@kernel.org>
References: 
 <CAAih9mhU-UKGvSKBsCqRmkN6zvsD_ThofU94tCOECVJ2G9iW=w@mail.gmail.com>
 <9b3e6161f290246eb8003767b2b34596a10f5d71.camel@kernel.org>
 <CAAih9miBhTWZVt2N_39tzzOfJfjyUKeq30tD2OOQZdQhRSFhSw@mail.gmail.com>
 <cd4e8b16a8c154e6bda38021eef2c0d56badb43c.camel@kernel.org>
 <71b3ff942fdf6f070f6cd59f29e04081d3f94c38.camel@kernel.org>
 <CAAih9mhcOq2XqL0Q0sgkrpfJudpL9knV8yq+Uk1s2mJRRxau8Q@mail.gmail.com>
 <6c16c58a9e6de330eab68aadd4714954df41dd1c.camel@kernel.org>
 <fe258f94cf0d4f4731d4affbb78777706692bd20.camel@hammerspace.com>
 <77344fe208d76fa98ba24d79f2246e34ae20b543.camel@kernel.org>
Date: Wed, 15 May 2024 19:59:22 +0800
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
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 repo=
rt
> 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.=C2=A0I'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.=20

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 applicati=
ons
don't check the result of close()

--=20
Hao Wei