Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1917457pxb; Fri, 24 Sep 2021 15:13:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynV5+2Cb91R+b99AGFExWHh7UhTYta6RlwM1gOtRmYAx1kgbGl0AKoapSkiLdvkkVpjq5d X-Received: by 2002:a5d:9693:: with SMTP id m19mr11025455ion.72.1632521637850; Fri, 24 Sep 2021 15:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632521637; cv=none; d=google.com; s=arc-20160816; b=zROwRfK0nskPpP2UooJJ7XkLoHUZmTZJ8qv5VxT29vpcMMnvrpvUiu/oTK0raFUCGZ yWP15dFOQWK4oAf2usTyZcx+XspxrKLfxpFE1RB4ozQ8IbxFC62WTSg66LuhUagvp86D Jn1gYEDmdbUCpNXPzpe22zPwyOkHpszFDNfRlP5Eafrd+Yz+L6xt+agMLNwQwNjtVPKI uk6FESet/JN9sPPgI2YDuKvtFesOboZkaRI9/Oi6l0CvHbr/E4Lg64lgNCdX3tpCwNeF Z/wHTiVqmCSTUrWpCkTWSNBecrPtsU9OfRI7QtXCD6qz+wX+pTmecj83DXM6Ikr5DqeD BvjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-filter; bh=jiFlW5P4EJb78zkwd+/lDROWq7Wav9LBFK4/hyCNR2M=; b=k+NDgu24d0Y5wRB/TI3HdLmncyta7aRz5szehHgnskQeobbQ3a8NrjVXOq8Kic+fWW WOZL9A9FS+yn/cHw1KTw7nrF9VyyeBoWQ/icu9qMIy5KSUZkVKQiWl5Q0geP1kz0Skuo 2bhE3KcIXb4r1EaNGri7BCkaXmGTK2KQfSW0tltecFjYl4DNlQ7aduvaCpbguWMKzdYx 5R0fCKWTHDj3iivvu0T9PDuhdUHu6zv2nzin7AsXMq+Q/tMOdfbLCyRP29cXv4D8JFgU 7oKxiStZLyKSlieNkXQncw3X1CmGVhgE5MPejbFEIDBDoxxMVMLNesjSzze4kgha0yJa dQ7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=U9QLfC4S; 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 v13si11308870ilj.176.2021.09.24.15.13.41; Fri, 24 Sep 2021 15:13:57 -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; dkim=pass header.i=@fieldses.org header.s=default header.b=U9QLfC4S; 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 S1346095AbhIXTF1 (ORCPT + 99 others); Fri, 24 Sep 2021 15:05:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229930AbhIXTF0 (ORCPT ); Fri, 24 Sep 2021 15:05:26 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 443E8C061571 for ; Fri, 24 Sep 2021 12:03:53 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id 359BF6814; Fri, 24 Sep 2021 15:03:52 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 359BF6814 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1632510232; bh=jiFlW5P4EJb78zkwd+/lDROWq7Wav9LBFK4/hyCNR2M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U9QLfC4SES3wJ6iDLfomIzKECxBEmhm8woNYUSIxTUOR59hNujwvsRS9iFmOvQCX3 MdYz3EI1cYyK+ZubYj8mxlioDZj/tXxwTGkIk1c38hRKYB+FvVuGjG2lJual0Ph5Pp Cz82c+lE49mR2gS4FNvZIavejUMOgiImLiuelAb0= Date: Fri, 24 Sep 2021 15:03:52 -0400 From: "J. Bruce Fields" To: Kazi Anwar Cc: linux-nfs@vger.kernel.org Subject: Re: nfs4err_delay Message-ID: <20210924190352.GD13115@fieldses.org> References: <20210924163948.GB13115@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, Sep 24, 2021 at 12:54:30PM -0500, Kazi Anwar wrote: > Yes, both clients and server are centos 7.6. And the NFS4ERR_DELAY is > a response to a REMOVE. > I will need to check on the locks the next time it happens. Can you > share what you are thinking? Offhand the only reason I can think a server would return DELAY is that there's a delegation on the file being removed, and the delegation recall and return isn't working for some reason. If that's the case, it should succeed after about 90 seconds. Also, you can workaround the problem by turning of delegations and leases with "echo 0 >/proc/sys/fs/leases_enable". --b. > > thanks, > Kazi > > On Fri, Sep 24, 2021 at 11:39 AM J. Bruce Fields wrote: > > > > On Wed, Sep 22, 2021 at 03:56:23PM -0500, Kazi Anwar wrote: > > > We are running nfs v 4.1 on centos 7.6. > > > We are seeing an NFS issue where when files/dirs are deleted from a > > > client they are occasionally stuck at unlinkat system call(according > > > to strace its stuck for 100.5 secs every time). Can anyone explain > > > this behavior? > > > Running tcp dump shows nfs4err_delay status sent from the server to > > > the stuck client. > > > > Client and server are both centos 7.6? > > > > Is the NFS4ERR_DELAY a reponse to a REMOVE? > > > > Does /proc/locks show a delegation held on the file the client's trying > > to remove? > > > > --b.