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:   Thu, 24 Jun 2021 16:36:36 -0400
From:   "J. Bruce Fields" <bfields@fieldses.org>
To:     dai.ngo@oracle.com
Cc:     chuck.lever@oracle.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC 1/1] nfsd: Initial implementation of NFSv4 Courteous
 Server
Message-ID: <20210624203636.GA4671@fieldses.org>
References: <20210603181438.109851-1-dai.ngo@oracle.com>
 <20210624140216.GB30394@fieldses.org>
 <c983218b-d270-bbae-71c5-b591bfbce473@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c983218b-d270-bbae-71c5-b591bfbce473@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Thu, Jun 24, 2021 at 12:50:25PM -0700, dai.ngo@oracle.com wrote:
> On 6/24/21 7:02 AM, J. Bruce Fields wrote:
> >I'm not sure how to deal with this.  I don't think there's an efficient
> >way to determine which expired client is responsible for an ENOSPC.  So,
> >maybe you'd check for ENOSPC and when you see it, remove all expired
> >clients and retry if there were any?
> 
> I did a quick check on fs/nfsd and did not see anywhere the server returns
> ENOSPC/nfserr_nospc so I'm not sure where to check? Currently we plan to
> destroy the courtesy client after 24hr if it has not reconnect but that's
> a long time.

The error normally originates from the filesystem.  Anything that might
need to allocate space could hit it, and it could happen to a non-nfsd
process.

I'm not seeing an easy way to do this; we might need ideas from other
filesystem developers.

--b.