Re: attempt to re-implement sillyrename for NFS in 2.1.*

Claus-Justus Heine (Heine@physik.rwth-aachen.de)
22 Aug 1997 23:52:20 +0200


> > One suggestion though ... I think it would be better for you to move the
> > sillyrename_cleanup to delete_inode. The main reason is that the
> > cleanup will block, possibly for quite a while, allowing the possibility
> > of the inode being put back in service. This has been a long-standing
> > race problem with put_inode.
>
> No.
>
> The problem is that "sillyrename_cleanup" has nothing to do with the
> inode. It depends _only_ on the 'dentry'. The inode may be around
> (indefinitely) with a non-zero count for hardlinks etc..
>
> This is why I haven't applied Claus-Justus' patches: they tried to handle
> this, but I don't like the way it was done. I think we should just add a
> "delete" (or "forget") function to the "dentry_operations" structure
> block, and call that from dput() when we put the last copy of the dentry.

Yes, that would be MUCH cleaner. My current hack keeps all that "silly
files" until the last user iputs the inode and and i_count goes down
to zero. This might lead to hundrets of ".nfs#ino" files. And the
directories that contain those files can't be removed either (dir not
empty).

> Then the NFS code would delete the silly rename where it is appropriate,
> without any hacks (no need to remove the dentry from the hash chains etc
> like Claus did).

Yup, because every "positive" dentry (i.e. d_inode != NULL) prevents
i_count from going down to zero.

> Claus: there was nothing wrong with your patches per se that I could see:
> it's just that I do not want to apply a silly-rename function that does it
> the "wrong" way in my opinion. I'm sure your patches work, and that's
> actually the main problem: if I were to apply something that works but is
> ugly, nobody else would ever be inclined to fix it up the correct way..

No problem, I just got fed up with the current NFS client code
w.r.t. Here scripts etc. And originally I didn't intend to change any
code outside the nfs client code.

> That's why I'm hoping that somebody would add a "delete" function to
> dentry->d_op, and in dput() the first thing it does when it notices that
> d_count goes down to zero it calls dentry->d_op->delete if the function
> exists..

.. which would delete that ".nfs#ino" files (in the case of NFS .. and
change the dentry to be a negative one? Have to look a closer look on
what happens to the unused dentries on the unused list when they get
reused)

> Any takers? Hint, hint..

If this is desired and I find the time, maybe.

Cheers

Claus