On Tue, Jun 29, 2021 at 4:45 AM NeilBrown <neilb@xxxxxxx> wrote: > > On Tue, 29 Jun 2021, bfields@xxxxxxxxxxxx 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? > To me, stale silly renamed files sounds like a problem worth fixing not as an excuse to create another similar problem. w.r.t pre-ENOSPC notification, I don't know of such notification in filesystems. It exists for some thin-provisioned storage devices (thinp as well I think), but that is not very useful for nfsd. OTOH, ENOSPC is rarely a surprising event. I believe you can get away with tunable for nfsd, such as % of available storage space that may consumed for "opportunistic caching". Polling for available storage space every least time or so in case there are possibly forgotten unlinked files should be sufficient for any practical purpose IMO. Thanks, Amir.
