Date: Wed, 21 Dec 2016 22:43:27 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Colin Percival <cperciva@tarsnap.com>, Don Lewis <truckman@FreeBSD.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <YTXPR01MB018946842963F9B6A6D39FA4DD930@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> References: <201612210325.uBL3PVtg006345@gw.catspoiler.org>, <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB018946842963F9B6A6D39FA4DD930>