From: "Theodore Ts'o" <tytso@mit.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-fsdevel@vger.kernel.org, dai.ngo@oracle.com,
linux-nfs@vger.kernel.org
Subject: Re: automatic freeing of space on ENOSPC
Date: Tue, 29 Jun 2021 12:47:11 -0400 [thread overview]
Message-ID: <YNtOjxXo4XJivFdw@mit.edu> (raw)
In-Reply-To: <20210628194908.GB6776@fieldses.org>
On Mon, Jun 28, 2021 at 03:49:08PM -0400, J. Bruce Fields wrote:
> Is there anything analogous to a "shrinker", but for disk space? So,
> some hook that a filesystem could call to say "I'm running out of space,
> could you please free something?", before giving up and returning
> ENOSPC?
In addition to the issues raised by Neil, Amir, Dave, and others, the
other challenge with the file system calling a "please try to free
something before I return ENOSPC" is that this would almost certainly
require blocking a system call while some userspace daemon tried to
free up some space --- or were you thinking that the nfsd kernel code
would be tracking all of the silly-rename files so it could release
space really quickly on demand?
Even if this is only a kernel callback, I'd be concerned about
potential locking hierarchy problems if we are calling out from block
allocation subsystem to nfsd, only to have nfsd call back in to
request unlinking a silly-renamed file.
So the suggestion that we not wait until we're down to 0 blocks free,
but when we hit some threshold (say, free space dips below N minutes
worth of worst or average case block allocations), trigger code which
deletes silly-renamed files, is probably the best way to go. In which
case, a callback is not what is needed; and if N is large enough, this
could done via a pure user-space-only solution.
- Ted
next prev parent reply other threads:[~2021-06-29 16:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 19:49 automatic freeing of space on ENOSPC J. Bruce Fields
2021-06-29 0:43 ` Trond Myklebust
2021-06-29 1:12 ` bfields
2021-06-29 1:43 ` NeilBrown
2021-06-29 4:07 ` Amir Goldstein
2021-06-29 18:34 ` bfields
2021-06-29 18:32 ` bfields
2021-06-29 18:39 ` Chuck Lever III
2021-06-29 5:11 ` Dave Chinner
2021-06-29 18:37 ` J. Bruce Fields
2021-06-29 16:47 ` Theodore Ts'o [this message]
2021-06-29 18:38 ` J. Bruce Fields
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=YNtOjxXo4XJivFdw@mit.edu \
--to=tytso@mit.edu \
--cc=bfields@fieldses.org \
--cc=dai.ngo@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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