Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4571811pxv; Tue, 29 Jun 2021 10:04:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz35dW46Pf51h3R2Aq4yHigO4oI2+iL63+f6EW9qjzfVNs6+o+iqIMSjogSj72U7llfJuWP X-Received: by 2002:a17:906:2b18:: with SMTP id a24mr31330126ejg.239.1624986256063; Tue, 29 Jun 2021 10:04:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624986256; cv=none; d=google.com; s=arc-20160816; b=o1XJ6zLCgG36OeIQQgrKqO5pH8ZDfigG+mX64sik+k7tAXoID29lAAabTUSrJvWXQN Py92yLgNQnXd6oVdO0E84SLgbusxd/bOPEolEP+Ze4aWKyN7yawcL2RZ/wJFi9rWhHBK NEdA6TBwVGwzTGn80U/yBw4Mu2CW8YvAKTKFlkD6ZI7LSMiRQaFalDmmYsdeI/BNR4T5 4B/i2XqoBfs9ex59P3r9DxOfUeN6EtD36qjUSp1aus/FdwO+TQ0wERetmUaYWnBMyQ/F ylN23tDkHhFCdfpavHXA5kRbAiKOfZTS80H4f5d/kLkjev83r8+dCIMiTTyjhmBs/bV6 A1Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Ubbtl8seuPLW6SAvjQeLd+jVjh59vLEKOxYqExtaINM=; b=EZ4dnDfKsPOXmmemzYlXHozxsAqqmRvbgXPYklMktyREUMm2uEBNaQG5ib+AfGmFfm JrISbEzz79d2dQ1T8MAjMIpjMi5K8LHl+x2rO7BBj4ocNdOp5KLQwsY6/ZtV05zQrl4a 7AvsjtIGEwdc1zvSQ8vjqIqhV1OWQ3LdOECvevZQf159FvAmlgAjV8RvEdJXsYEWRAf/ a5OGGUs+I1S81Mq4cIotwthjjbkTBuRvGW201jh+EZZ+TWYkSk+2fMKSkDRPPEVhfQ6o IlKnNp+AzXhEkgJRhl6RZE5VZZlTOZWewyPIJ6HaxHv/zcN07HG30cExq3tOjw6PR151 5klA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 7si10159199edw.24.2021.06.29.10.03.49; Tue, 29 Jun 2021 10:04:16 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233843AbhF2Qtr (ORCPT + 99 others); Tue, 29 Jun 2021 12:49:47 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:55363 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232441AbhF2Qtq (ORCPT ); Tue, 29 Jun 2021 12:49:46 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15TGlBrx004287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Jun 2021 12:47:12 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id B5CB515C3CD8; Tue, 29 Jun 2021 12:47:11 -0400 (EDT) Date: Tue, 29 Jun 2021 12:47:11 -0400 From: "Theodore Ts'o" To: "J. Bruce Fields" 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: 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 List-ID: X-Mailing-List: linux-nfs@vger.kernel.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