Messages in this thread | | | Subject | attempt to re-implement sillyrename for NFS in 2.1.* | From | Claus-Justus Heine <> | Date | 21 Aug 1997 22:59:51 +0200 |
| |
There recently were some postings about -ESTALE errors with e.g. "Here" scripts on NFS file systems with 2.1.* and problems with nis and some other problems.
The reason for those errors is the missing support for that "sillyrename" stuff that we had with the 2.0.* implementation of the nfs code.
I dared to try to re-implement it. The hack included below has the following features:
The 2.0.* sillyrename code uses ".nfs#ino" for the temporary files where "#ino" is the DECIMAL representation of "inode->i_ino". Now, "inode->i_ino" has type "unsigned long" and thus may be 64 bit wide. The old code uses only 16 chars for the ".nfs#ino" name which will not be enough for 64 bits. Therefore I switched to a HEXADECIMAL representation with enough space for a 64 bit value. Thus the number of chars for ".nfs#ino" is simply "sizeof(unsigned long)*2+5".
The patch allows for one temporary ".nfs#ino-number" file for each directory an inode was linked into. This is necessary as the nfsd (at least the Linux user-land nfsd) generates different file handles for the same inode if it is contained in different directories (i.e. with cross-directory links); the nfsd also generates a different NFS file-handle when a file is renamed across directory boundaries. I tried to support the latter following a suggestion of Olaf Kirch:
do a "sillyrename()" in the original directory, then create a link to the new location.
Of course, sillyrename() is only needed when a file is held open by some application while it is moved or unlinked.
As a check whether a file indeed is in use, I tried the following construct:
if (dentry->d_inode->i_count > 1 || dentry->d_count > 1) { then this inode is used by more than one application }
I had the impression that this is sufficient, because:
Each dentry on the alias list has called iget() separately. Therefore i_count >= #dentries on the alias list of that inode. Please FIXME.
There are quite some comments in the patch to fs/nfs/dir.c
Below there is also a short script that tries to create test cases for the patch, i.e. it creates multiply linked files held open by applications while the inode is unlinked, and moves files accross directory boundaries while they are still being accessed by some other application. The script is ugly enough, but maybe sufficient to get an idea of the problem (when running it on plain 2.1.51 compared to the patched version).
Not to be forgotten: the patch is relative to a plain 2.1.51 kernel and might work or might not work. Test it yourself.
Cheers
Claus
[unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] Claus-Justus Heine claus@momo.math.rwth-aachen.de http://samuel.math.rwth-aachen.de/~LBFM/claus
PGP Public Key: http://samuel.math.rwth-aachen.de/~LBFM/claus/claus-public-key.asc
Ftape - the Linux Floppy Tape Project WWW : http://samuel.math.rwth-aachen.de/~LBFM/claus/ftape Mailing-list: linux-tape@vger.rutgers.edu [unhandled content-type:application/pgp-signature] | |