lkml.org 
[lkml]   [1997]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: attempt to re-implement sillyrename for NFS in 2.1.*
From
Date
> > 
> > I thought silly rename was generally used only to support temp files
> > with nlink = 1.
>
> That's the usual case, but it really has to work for linked files too.

And my hack already handles this. As far as I can tell from your
feedback, the main problem is how and when to delete the silly inode's
dentry instances (and the "silly files" on the NFS server).

> > If the sillyrename is handled at the dentry level, doesn't that also
> > imply that the state associated with the rename will also need to be
> > stored at the dentry? If the inode has nlink > 1, it might undergo
> > silly renames in other directories where it appears, and need separate
> > state for those.
>
> The whole silly-rename thing is a dentry-level operation, and doesn't
> actually need to look at nlink at any point. The logic goes:

My hack actually doesn't look at nlink.

> 'inode->i_op->unlink()':
> - look at "dentry->d_count": if it is > 1 we need to sillyrename,
> because somebody has the file open still so we can't delete it
> at the server.

Actually, one would need only a single temp file for each directory.
Consider multiply linked files:

There is a dentry for each link. Say, it was the file "foo" which is
also linked to the file "fii" (in the same directory, for simplicity).

Now, when --- I'm stupid. Yes. The NFS serves takes care of this.

However, on the server side the proper name for the temp file still is
".nfs#ino" (one per directory).

> - if dentry->d_count == 1, delete the file.
>
> 'dentry->d_op->delete()':
> - look if we are silly-renamed (use "dentry->d_flag" for this, it's
> usable for filesystem specific things). If so, do the actual NFS
> server delete.
>
> So at no point is "i_nlink" implicated.
>
> Note that the silly-name can (and should) be shown in dentry->d_name (so
> dentry->d_op->delete can just use the dentry name directly, and doesn't
> necessarily even know about what the naming logic is). This allows silly
> renaming to work even if the user has _moved_ the silly renamed file
> (something that never worked with the old code - the silly rename stuff
> just got terminally confused).

I don't think that the user should be allowed to move active "silly
renamed" files. My main objection is:

At least the Linux user land nfsd creates a different NFS file handle
if a file is moved cross directory boundaries. And this will again
result in that "-ESTALE" errors.

Also, why should one allow those .nfs#ino file to be really recovered?
The best solution, IMHO, would be to hide them at all. But THAT would
be REALLY messy.

My current hack refuses unlink and renaming of active "silly renamed"
files with an EBUSY error. I think that this is quite convenient, and
makes it unnecessary to take more complicated stuff into account, like
moving that "silly files" to other directories etc.

MMh. Better first try to hack that d_op->delete() stuff and have a
look how powerful it is.

Cheers

Claus


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.090 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site