linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: linux-fsdevel@vger.kernel.org
Cc: dai.ngo@oracle.com, linux-nfs@vger.kernel.org
Subject: automatic freeing of space on ENOSPC
Date: Mon, 28 Jun 2021 15:49:08 -0400	[thread overview]
Message-ID: <20210628194908.GB6776@fieldses.org> (raw)

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?

The NFS server currently revokes a client's state if the client fails to
contact it within a lease period (90 seconds by default).  That's
harsher than necessary--if a network partition lasts longer than a lease
period, but if nobody else needs that client's resources, it'd be nice
to be able to hang on to them so that the client could resume normal
operation after the network comes back.  So we'd delay revoking the
client's state until there's an actual conflict.  But that means we need
a way to clean up the client as soon as there is a conflict, to avoid
unnecessarily failing operations that conflict with resources held by an
expired client.

At first I thought we only needed to worry about file locks, but then I
realized clients can also hold references to files, which might be
unlinked.  I don't want a long-expired client to result in ENOSPC to
other filesystem users.

Any ideas?

I searched around and found this discussion of volatile ranges
https://lwn.net/Articles/522135/, which seems close, but I don't know if
anything came of that in the end.

--b.

             reply	other threads:[~2021-06-28 19:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 19:49 J. Bruce Fields [this message]
2021-06-29  0:43 ` automatic freeing of space on ENOSPC 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
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=20210628194908.GB6776@fieldses.org \
    --to=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;
as well as URLs for NNTP newsgroup(s).