From owner-freebsd-fs@freebsd.org Fri Dec 16 20:15:02 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADB78C83B02 for ; Fri, 16 Dec 2016 20:15:02 +0000 (UTC) (envelope-from 010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@amazonses.com) Received: from a8-176.smtp-out.amazonses.com (a8-176.smtp-out.amazonses.com [54.240.8.176]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B53E927 for ; Fri, 16 Dec 2016 20:15:02 +0000 (UTC) (envelope-from 010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1481919293; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=U5WpkV6CS3uFMsOMwY+QsfSQVSkdfgUWB+6nA7gX6W0=; b=Mo3uWstTHnpYIROr8FFvTS/iYpBqngppb/fOgvt9QdDkAfobiWo6q1LlkTY6dAvu 704QiAGptc2YL3O5p2ehuAR5+XgLB4O3B8JwqFevlettv3PU7qiuEdQZ9zUVa8OtDRt 9+EdlrkR9gSPLvlwG6+cA8cXN4Zx9GQuraEcnmhg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1481919293; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=U5WpkV6CS3uFMsOMwY+QsfSQVSkdfgUWB+6nA7gX6W0=; b=atV+EKuGgaP0yp8YLVs06uGNeRGKXcP0H/j0Bn18eYTFwm7hC5b+L/ZKMtBt0+/r 2y929H7j8vybv/Fi+tXGxNakTtRVO6NG8DBwYozZxBYmU7qyUGg6RDNcNQXGmokPls0 EezgLg+nOL8bGqNSDFvy1bG8CBIy8upHXDuP5auM= Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> <20161212054233.GU8460@kduck.kaduk.org> <01000158f1abc081-d4eddc58-3b4b-41dd-aa1e-0157d2fad812-000000@email.amazonses.com> <20161212163603.GV8460@kduck.kaduk.org> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> Cc: "freebsd-fs@freebsd.org" From: Colin Percival Message-ID: <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com> Date: Fri, 16 Dec 2016 20:14:53 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.16-54.240.8.176 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 20:15:02 -0000 On 12/15/16 15:17, Rick Macklem wrote: >>>>>> On Sun, Dec 11, 2016 at 11:06:42PM +0000, Colin Percival wrote: >>>>>>> If I run the following with /nfs/ being an NFS mount: >>>>>>> # mkdir /nfs/foo >>>>>>> # touch /nfs/foo/bar >>>>>>> # cd /nfs/foo >>>>>>> # rm -r /nfs/foo >>>>>>> # rm bar > > I will try and play with this when I get home, but you could test the following > simple change: (I'll just explain the patch, since I don't have sources handy) > In sys/fs/nfsclient/nfs_clvnops.c: > Line #s 1678, 1679 (for remove) and 2180, 2181 (for rmdir) look like: > if (error == ENOENT) > error = 0; > This is done since, if it doesn't exist, it has been "removed". > It seems to me that ESTALE means it has been removed too. > (Actually the directory the name was in has been removed, but that implies that > the name is gone too.) This doesn't fix the problem. This particular ESTALE is coming earlier, from nfsrpc_lookup, when we attempt to look up a path relative to a directory which no longer exists (and thus through a file handle which is stale). Interestingly, making this change in nfs_lookup > --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) > +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) > @@ -1144,7 +1144,7 @@ > *vpp = NULLVP; > } > > - if (error != ENOENT) { > + if (error != ENOENT && error != ESTALE) { > if (NFS_ISV4(dvp)) > error = nfscl_maperr(td, error, (uid_t)0, > (gid_t)0); fixes the case I described above (for some definition of "fixes" -- I'm not sure if this is the correct way of handling ESTALE here?) but I'm still seeing ESTALEs from buildworld's cleandir so I think there must be some other place where something odd is happening. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid