Re: NFS sillyrename side effect

["Cláudio Martins" <ctpm-s6mEjpzMaPUVhHzd4jOs4w@public.gmane.org>]

On Mon, 18 Oct 2010 11:01:38 -0400 Jeff Layton <jlayton@redhat.com> wro=
te:
> On Mon, 18 Oct 2010 15:53:44 +0100
> Cl=C3=A1udio Martins <ctpm-s6mEjpzMaPUVhHzd4jOs4w@public.gmane.org> wrote:
>=20
> > >=20
> > >  So, theoretically, could one modify the code to selectively disa=
ble
> > > silly rename on a client, when it knows it is talking v4 with the
> > > server?
> > >=20
> >=20
> >  BTW, to clarify, I'm assuming a scenario where the server is
> > configured to talk v4 only, which I suspect should be common, at le=
ast
> > when you're relying on v4 kerberos security.
> >=20
>=20
> Sadly, no...
>=20
> The server does generally hold the file open as long as the client ha=
s
> the file open. So, you could delete the file while nfsd has it open a=
nd
> everything would probably still work.
>=20
> Suppose though that the server crashes and reboots. When it comes bac=
k
> up, fsck figures out that the file has been unlinked and frees the
> blocks on the disk. Now you can't reclaim the state on the open file.
>=20
> We're pretty much stuck with silly-renaming even for v4.
>=20

 Jeff,

 Thank you for the explanation, you make a good point.

Best regards

Cl=C3=A1udio