From owner-freebsd-fs@freebsd.org Tue Dec 13 13:36:12 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 2D3B6C75B8F for ; Tue, 13 Dec 2016 13:36:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0067.outbound.protection.outlook.com [157.56.110.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9AEB1D5D for ; Tue, 13 Dec 2016 13:36:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM (10.169.141.138) by YQBPR01MB0177.CANPRD01.PROD.OUTLOOK.COM (10.169.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Tue, 13 Dec 2016 13:04:06 +0000 Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) by YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) with mapi id 15.01.0771.014; Tue, 13 Dec 2016 13:04:06 +0000 From: Rick Macklem To: Benjamin Kaduk , Colin Percival CC: "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrA== Date: Tue, 13 Dec 2016 13:04:06 +0000 Message-ID: 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> In-Reply-To: <20161212163603.GV8460@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: d24c79e7-655e-4b2f-ecf8-08d42358854a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YQBPR01MB0177; x-microsoft-exchange-diagnostics: 1; YQBPR01MB0177; 7:N9vRmQ6EI07LkTzgEi5G+j9BIdiSexSeRVTrRfCD3n1tmXVQpdERlc9CvKntqj72Y6WQYcLuwA+u0ZC7j7tLTVcexcdOacWj7gzglFXmAhsz1QMIoYdOzJG3FyWfWENTF1D5xL8VdBR1OnqjeakM3olxowuKl3U4r1D+GUlFXWyKAdNqkz0sMYdLqPz2WsdJWlvtqScf1nZnzAkieoiMjvd7jYg9WM/REgO5TRM/fDSQTQ/sg1EXHvACCxVok46w8ycalGdGqpOwY4pq6IoGQ4KIN+ujNc0XzZPR2aaIBmEywaRe+0XCqmv6ETCw4ai+yT28MghoUNCLfqkHMasw0AUW5RC3dnYWzSTHcWwlFbS6fRokytZKaW1CC7gEspV/7a4RY6Sjw7LNsHdGm9jGdNkbqWvvMDwGnS44dKpNfzGptbA62jBPxQB7PgVM12HZZ26BhxDqBn+gXDBub6WBcg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:YQBPR01MB0177; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0177; x-forefront-prvs: 01559F388D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(51444003)(9686002)(3280700002)(93886004)(74482002)(3660700001)(305945005)(4326007)(2906002)(2900100001)(92566002)(2171001)(102836003)(81166006)(81156014)(8676002)(8936002)(68736007)(5660300001)(74316002)(7696004)(86362001)(122556002)(2950100002)(106356001)(105586002)(106116001)(38730400001)(77096006)(229853002)(189998001)(54356999)(5001770100001)(97736004)(50986999)(76176999)(33656002)(101416001)(6506006)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0177; H:YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2016 13:04:06.0421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0177 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 13:36:12 -0000 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 fa= il 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 s= erver, 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 opt= ional case of a server that can retain files after an NFSv4 Remove until the NFSv4 Cl= ose, 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=3D1 (or something close to disable_vnfullpa= th) 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, whi= le 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