On Thu, Jun 24, 2021 at 12:50:25PM -0700, dai.ngo@xxxxxxxxxx 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.
