linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Dave Chinner <david@fromorbit.com>
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 14:37:41 -0400	[thread overview]
Message-ID: <20210629183741.GC1926@fieldses.org> (raw)
In-Reply-To: <20210629051149.GP2419729@dread.disaster.area>

On Tue, Jun 29, 2021 at 03:11:49PM +1000, Dave Chinner wrote:
> On Mon, Jun 28, 2021 at 03:49:08PM -0400, J. Bruce Fields wrote:
> > 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.
> 
> I'm not sure what you are asking for filesystems to do here.  This
> seems like an application problem - revoking the client's open file
> state and cleaning up silly rename files is application level
> garbage collection, not filesystem level stuff.

Right, the "application" in this case is knfsd.  It may be keeping some
unlinked files around that it doesn't really need to.  So I'm basically
wondering if I could get a notification from the filesystem that now
would be a good time to close those files.

I think Neil's convinced me this isn't a priority, though....

--b.

  reply	other threads:[~2021-06-29 18:37 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 [this message]
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=20210629183741.GC1926@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=dai.ngo@oracle.com \
    --cc=david@fromorbit.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).