Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "bfields@fieldses.org" <bfields@fieldses.org>
Cc:     "Trond Myklebust" <trondmy@hammerspace.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "dai.ngo@oracle.com" <dai.ngo@oracle.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: automatic freeing of space on ENOSPC
In-reply-to: <20210629011200.GA14733@fieldses.org>
References: <20210628194908.GB6776@fieldses.org>,
 <9f1263b46d5c38b9590db1e2a04133a83772bc50.camel@hammerspace.com>,
 <20210629011200.GA14733@fieldses.org>
Date:   Tue, 29 Jun 2021 11:43:45 +1000
Message-id: <162493102550.7211.15170485925982544813@noble.neil.brown.name>
Precedence: bulk

On Tue, 29 Jun 2021, bfields@fieldses.org wrote:
> On Tue, Jun 29, 2021 at 12:43:14AM +0000, Trond Myklebust wrote:
> > How about just setting up a notification for unlink on those files, the
> > same way we set up notifications for close with the NFSv3 filecache in
> > nfsd?
> 
> Yes, that'd probably work.  It'd be better if we didn't have to throw
> away unlinked files when the client expires, but it'd still be an
> incremental improvement over what we do now.

I wonder how important this is.  If an NFS client unlinks a file that it
has open, it will be silly_renamed, and if the client then goes silent,
it might never be removed.  So we already theoretically have a
possibilty of ENOSPC due to silent clients.  Have we heard of this
becoming a problem?
Is there reason to think that the Courteous server changes will make
this problem more likely? 

NeilBrown