Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 29 Jun 2021 15:11:49 +1000
From:   Dave Chinner <david@fromorbit.com>
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
Message-ID: <20210629051149.GP2419729@dread.disaster.area>
References: <20210628194908.GB6776@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210628194908.GB6776@fieldses.org>
Precedence: bulk

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?

The only thing the filesystem can do at this point is run internal
garbage collection operations to free up space that it has either
speculatively allocated or has deferred the freeing and/or cleanupi
of. In general, filesystems already do this when they are
approaching/at ENOSPC, so it seems to me like there's little scope
for an external "free some space" trigger to be able to make much
difference.

I mean, we do have an ioctl in XFS to trigger garbage collection of
speculative preallocation from userspace (XFS_IOC_FREE_EOFBLOCKS
and the prealloc command in xfs_spaceman(8)) but this was written
because some people want accurate space accounting for things like
quota reports....

Regardless, we run these same GC triggers internally before we
declare ENOSPC, so there's no real need for applications to run them
when they get an ENOSPC error....

> 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. Maybe I've
misunderstood what you are trying to do, perhaps you could clarify
what you're expecting the filesystems to be able to clean up here?

> 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.

Nothing that I know of.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com