From owner-freebsd-fs@freebsd.org Thu Dec 22 01:16:17 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 08912C8ADD8 for ; Thu, 22 Dec 2016 01:16:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0052.outbound.protection.outlook.com [104.47.38.52]) (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 A676122D; Thu, 22 Dec 2016 01:16:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 22:43:27 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 22:43:27 +0000 From: Rick Macklem To: Colin Percival , Don Lewis 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: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wSAAJ6iAIABFdOMgAA8WICAAAnSAIABOPDS Date: Wed, 21 Dec 2016 22:43:27 +0000 Message-ID: References: <201612210325.uBL3PVtg006345@gw.catspoiler.org>, <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> In-Reply-To: <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> 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: 57217a5b-6c0b-4c82-7966-08d429f2c7da x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0190; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:3tHAR1VMsCqP3qvrcz36P5kyEewA/VFRcm4iF5AWufbiYsjC92d1+pSeA/Y0xptaqv8/dICWmaLDuVW6EVT5MkKjjBmYWLu4sa1FEkF3CwoQYD2D5zlIbkGRY0fjyVsXoauUE5BX4X66wGsF4yhyJCvE1e4ly4wxTxGsrgWTYtWsBQJBFbyllvQMOef2VHpoihhsL4LKN2s5uEzlCBdlbJzBX5i+qFmCq3mGGQbhVZNAfOcRE8swUADnQdwutALrXLjEKhcHc2Zn5VjAV+HV6lH44KvwKB7FhwhTwoxqoOxTeQkeUCkreQ1tPc6+FlnD54iwsj2H6UCdkIZHPPnE+xjf8FnDdqdRIjrlnH0ALnBgYrySN/XFD2lSr1OLIFy9Ugmwr5Kx431PsxL5B5c07YEkprhU4lxNeUXOX5SWjTRTcK+b7oaS7N/RYeh72WnV9lX7+HiYl04lGt2w0fNnoQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(54356999)(229853002)(122556002)(92566002)(74316002)(305945005)(106356001)(102836003)(105586002)(8676002)(2900100001)(9686002)(106116001)(8936002)(81156014)(81166006)(68736007)(6506006)(38730400001)(86362001)(101416001)(77096006)(33656002)(6436002)(2906002)(74482002)(4326007)(3660700001)(97736004)(5660300001)(189998001)(5001770100001)(7696004)(3280700002)(50986999)(2950100002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.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: 21 Dec 2016 22:43:27.5348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 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: Thu, 22 Dec 2016 01:16:17 -0000 Colin Percival wrote: >On 12/20/16 19:25, Don Lewis wrote: >>>> Colin Percival wrote: >>>>> In UFS there are checks for effnlink =3D=3D 0 which result in e.g. uf= s_lookup >>>>> returning ENOENT; would it make sense to add NREMOVED to struct nfsno= de.n_flag >>>>> and check this in the appropriate nfs_* calls? >> >> It sort of seems like this should be handled at the vfs level. Once >> rmdir() succeeds, there should be no calls to the underlying fs code. >> Maybe add a deleted flag to the vnode ... > >Or perhaps to the nfsnode, as I suggested a few emails ago? > >> Dunno how ufs and zfs handle this, but the right thing happens: > >I haven't looked at ZFS, but in UFS there are checks for effnlink =3D=3D 0= which >result in calls returning ENOENT. As I already mentioned to Colin, there is also the case where another clien= t did the "rmdir" and the ESTALE will happen for that case, so mapping ESTALE->ENOENT seems to me to be a simple (and maybe more general) solution for NFS. rick