Thread (12 messages) 12 messages, 7 authors, 2021-06-29

Re: automatic freeing of space on ENOSPC

From: Amir Goldstein <amir73il@gmail.com>
Date: 2021-06-29 04:08:03
Also in: linux-fsdevel

On Tue, Jun 29, 2021 at 4:45 AM NeilBrown [off-list ref] wrote:
On Tue, 29 Jun 2021, bfields@fieldses.org wrote:
quoted
On Tue, Jun 29, 2021 at 12:43:14AM +0000, Trond Myklebust wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help