From owner-freebsd-fs@freebsd.org Tue Dec 20 04:33:48 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 1921DC87BA1 for ; Tue, 20 Dec 2016 04:33:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0053.outbound.protection.outlook.com [104.47.33.53]) (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 B67CA1D83 for ; Tue, 20 Dec 2016 04:33:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 21:59:59 +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; Mon, 19 Dec 2016 21:59:59 +0000 From: Rick Macklem To: 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: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wQ= Date: Mon, 19 Dec 2016 21:59:59 +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> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com>, <0100015915a5ee96-49de6100-5050-4a0a-a3c9-1bd4215bc6a0-000000@email.amazonses.com> In-Reply-To: <0100015915a5ee96-49de6100-5050-4a0a-a3c9-1bd4215bc6a0-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: 814fc361-6698-4447-255a-08d4285a607e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:JS/pPHYlNv9mSzN9Ib4jyS8EX5Tb4Tc7HSBki4VmmZvAevYhAmRl+JK5cbc6FtRB9svAWZzcMtAClBaXOC/8tekMSl97MgBdF0y6qCb1mPCd8Zm+aomhfvagcClc2747gT2/KdkJr0BrFXWkTe2CMaQKaYHaD9gxpYXoDRFHe6N8HKxBhd9QWlRbJM/XFYaSqcApSZ0B1fNvHvUUZWCkxO/w8zZZGOSbmui3l559/L7AzXmBHwPqpjhAyIlbI5t+Ym9MFdIBPrxIQSPeQLoDaTCU/HFh0G+LVbuvaLCZ2tsm1MrLLzV2KjaPpws2DAjopXLy9Gk1dZrk9pGQZ+C+7bEKvHaMuz9csK0rDG22v6e8oBwysET8AB91Jq+9mNc/yXynvDatSDEJPxoDGtboUjK2duR5YRQ0zrrI0zPE/1Ih+Bi85y64yfyr02zYLnRXpQfco5TS2LojRp0W401wYw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(189002)(199003)(102836003)(189998001)(5660300001)(305945005)(74316002)(8936002)(2950100002)(110136003)(4326007)(2906002)(122556002)(68736007)(6916009)(74482002)(97736004)(76176999)(81166006)(54356999)(106356001)(229853002)(81156014)(77096006)(38730400001)(86362001)(106116001)(6506006)(101416001)(3660700001)(33656002)(6436002)(2900100001)(9686002)(93886004)(92566002)(50986999)(7696004)(3280700002)(8676002)(105586002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; 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: 19 Dec 2016 21:59:59.5358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 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, 20 Dec 2016 04:33:48 -0000 Colin Percival wrote: >On 12/16/16 12:14, Colin Percival wrote: >> 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 =3D NULLVP; >>> } >>> >>> - if (error !=3D ENOENT) { >>> + if (error !=3D ENOENT && error !=3D ESTALE) { >>> if (NFS_ISV4(dvp)) >>> error =3D 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 p= lace >> where something odd is happening. > >Further information: In addition to the "lookup relative to a directory wh= ich >has been deleted out from underneath us" case which causes ESTALE to land = in >nfs_lookup, the cleandir step of buildworld results in ESTALE being return= ed >by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and EST= ALE >being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimate= ly >in stat and lstat). > >In UFS there are checks for effnlink =3D=3D 0 which result in e.g. ufs_loo= kup >returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_= flag >and check this in the appropriate nfs_* calls? To be honest, I can't think of a reason why userland would ever want to see= ESTALE? The function you see above "nfscl_maperr()" could easily map all ESTALEs to= ENOENTs? - The question is: "Would returning ENOENT for stat(2) and access(2) actual= ly make the buildworld happy? if Yes - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx() = calls. else - I don't see any point in returning a different error and there= might be some code out there somewhere that depends on seeing ESTALE (I doub= t it, but???). The real problem here is that the directory has a reference count on it whe= n it is rmdir'd. POSIX file systems keep the data until the reference count goes to= 0, but NFS isn't POSIX. --> The cheat for regular files is "sillyrename". This could be done for di= rectories, but there are multiple comments in the code (not put there by me) tha= t say "no sillyrename for directories". #1 Does this imply something breaks when you do sillyrename for dirs? OR #2 Does it mean no one has bothered to implement it? Since implementing it would have been pretty easy, I have to suspect #1, wh= ich means I would be reluctant to do it, at least by default. --> Maybe I'll send you a patch that does sillyrename for dirs which you ca= n test. If it fixes buildworld, then it could be considered for head as a non= -default option? rick