From owner-freebsd-fs@freebsd.org Tue Dec 13 14:09:55 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 816E2C74EE3 for ; Tue, 13 Dec 2016 14:09:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4591F18D2 for ; Tue, 13 Dec 2016 14:09:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-oi0-x22b.google.com with SMTP id b126so123644263oia.2 for ; Tue, 13 Dec 2016 06:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+NdinlcwIipK2AxQ+52YkcDL3y172tlBEWhb8NtIA2M=; b=WM1HJHklL63PxUWvAm2MgB6DogOLcerulK4hphHD+cBQQAzlZPLdfjyp9U2vdaUUpc p/YeGlKosT6YT/EEZ/RKhYsSs+DrRgs+4Z3vu5B6bogNwuG/I9e8CromCPDLNYWotovj 2+uJpVipFJOmJCTmEtvyHGF/WqwTlw+zVRJpGX09/CQaR6/0PbGf3bDX+I91N35qYKxb FKjLLUvvWkoLGTJoFai0vCiNZGDAAYK2DPOD97cx6WFH1vbwx7rsEtQcUXgf+uAwY+Sl 89gSP43of0qmLW39cNcHytq7iMqwJu2VbjRpkXO/wwGN6pdVxj6JMdWOE2YBHH6Y3zZt JYow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+NdinlcwIipK2AxQ+52YkcDL3y172tlBEWhb8NtIA2M=; b=M7s+p+28rREZyV62bqvB7KzmLBWpelUd1fKXTr6Szlhc9FP0xwgajQgPLX/n01tZYv 8iiS3QcsegorzwfsgNi3i5qosvL9GRQMSdVI06EaK49+IpyF97FHvM/aANwl2yy1i26r bxzfgdUBdmrEPHstfxq5V/Qv8qfDXVDZiB9R9a+PBaaF2T0ZLKHXH16L1/FXal1v+zBK WN2aHWlOSCr6QSIDZZgnlhqXuCtzmqHLWzKJKtDkBcMV+xELUdTdoobbiLv5CUKBXw52 YBUA7Ej6ENexeJZeciSXJRJct8usnfiJCLlQb0F5OQRIIC4qhX+hrMVun4DliNeFvYOA SfyQ== X-Gm-Message-State: AKaTC02Na0oTZwv/EOW2yjy7vRzS0nMobWw+qS3bf12Qml5uz9Rq3yf6fs+W3A+lGj9e4aBGniNWixP2ncQ8OA== X-Received: by 10.157.11.72 with SMTP id p8mr53713588otd.146.1481638194638; Tue, 13 Dec 2016 06:09:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.213.229 with HTTP; Tue, 13 Dec 2016 06:09:54 -0800 (PST) In-Reply-To: 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> From: Doug Rabson Date: Tue, 13 Dec 2016 14:09:54 +0000 Message-ID: Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem Cc: Benjamin Kaduk , Colin Percival , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Tue, 13 Dec 2016 14:09:55 -0000 OPEN4_RESULT_PRESERVE_UNLINKED is described in the NFSv4.1 RFC On 13 December 2016 at 13:04, Rick Macklem wrote: > Benjamin Kaduk wrote: > > >On Mon, Dec 12, 2016 at 06:15:14AM +0000, Colin Percival wrote: > >> On 12/11/16 21:42, Benjamin Kaduk 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 > If this is happening on a single client, something is broken. > - For this step, the name cache should have a miss and the Lookup should > fail with > ENOENT. I think the most likely failures are... > --> Either the name cache in the client is broken and has a hit > OR > --> The server replies NFS_OK for the lookup, even though it should have > been removed. > > When I get home on the weekend, I'll try this against a FreeBSD and Linux > server, to see > if it fails. If it does, then I'll try to figure out why. > (Version of NFS shouldn't matter for this case. They recently added the > optional case > of a server that can retain files after an NFSv4 Remove until the NFSv4 > Close, making > it more POSIX like. I think that's NFSv4.2, but it might be in NFSV4.1.) > > Did you try: > sysctl debug.disable_vnfullpath=1 (or something close to > disable_vnfullpath) > to see if it helped? > > rick > > >> >> > >> >> Then the final 'rm bar' fails with 'Stale NFS file handle'. > >> > > >> > Amusingly, this just came up recently: > >> > > >> > https://www.ietf.org/mail-archive/web/nfsv4/current/msg15115.html > (et seq) > >> > > >> > But I guess you did not specify which version of the NFS protocol you > were > >> > using... > >> > >> I'm using NFSv4.1, but this isn't quite the same... that link refers to > having > >> one NFS client remove a file out from underneath a different client, > while I'm > >> talking about having an NFS client remove a file from underneath > *itself*. > > > >I thought the reply mentioned (in passing) the case of a client removing a > >file out from under itself as well. But, maybe I was reading too fast. > > > >-Ben > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >