Messages in this thread | | | Date | Thu, 7 Oct 1999 14:40:13 +1000 (EST) | From | Neil Brown <> | Subject | Re: knfsd 1.5 is released |
| |
On Friday October 1, hjl@valinux.com wrote: > > It is too much change for me. I fixed it in a different way in > 1.5.2. > > -- > H.J. Lu (hjl@gnu.org)
"Fixed" is kind of an interesting verb....
I have just been browsing through 1.5.2. Let me tell you some of what I found.
In nfsd-2.2.12-2.mountd.patch:
- There is a new export flag, NFSEXP_REJECTED. fh_verify will set it on any NFSEXP_NEGATIVE export entry that was used to reject a request (with ESTALE). Seems reasonable, but why? Lets see...
- There is a new function, exp_get_rejected which searches through all exports for all clients looking for an NFSEXP_REJECTED export entry. If it finds one it removes it from the export table and returns it. exp_export (which implements the system call to add entries to the exports table) call this fairly early and if it gets back an entry it uses it instead of kallocing new memory for the new export entry. Why? well I guess this helps auto-expire negative entries, once they have been used at least once, but it seems a bit random. At the very least, some sort of LRU ordering would seem appropriate. I would prefer removals to be explicitly managed by some user-level process that has access to a last-used-time for each export entry.
But on to the more relevant stuff:
- nfsd_netlink_notify ( which is called when an export entry cannot be found) constructs a message consisting of: . The sockaddr_in of the client that is making a request. . the knfs_fh file handle (the 32byte filehandle in a suitable structure) of the request . The path name of the file being accessed . The path name of the filesystem containing the file (these two are grouped together into a single char[] array.)
Then in utils/mountd/mountd.c: nlfd_handler (which is given these messages when they arrive):
- calls get_rootfh with the client address and file pathname, much as mountd does when responding to the MOUNTD_MNT request, which will try to find a relevant export entry and will feed it to the kernel. If this worked and the export entry has the same xdev/xino as the filehandle, then all is ok. This seems fine.
But what happens if it doesn't find an appropriate mount entry, or if the the xdev/xino is wrong?
First to clarify what needs to happen here: A NFSEXP_NEGATIVE export entry needs to be given to the kernel with an appropriate client, and with exactly the xdev/xino out of the filehandle. If not, then when this request is retransmitted, the same process will be repeated.
So what does nlfd_handler do? First it stats the path to the file being accessed to see if it has the right xdev/xino. The chances of this are probably "poor" in general, though it might work in certain senarios. If it isn't the right xdev/xino, then it stats the filesystem that contained the filehandle, and assumes that this will have the right dev/ino. If it was the root of the filesystem that was exported, this will work fine (as would previous versions). If it wasn't then this will not have the right dev/ino.
In either case, the dev and ino of the last stat is used to create a negative export entry which is feed to the kernel.
So, what happens when we:
have a filesystem /a export /a/b to fred on fred, mount /a/b as /ab on fred, cd /ab/c (which we assume exists) on server, unexport /a/b to fred on fred, ls -l . Fred will send some sort of request with the filehandle it got for /a/b/c. This will have a dev/ino referring to /a/b/c and an xdev/xino referring to /a/b.
knfsd will pass the filehandle and path names up to mountd which will: try to see if /a/b/c (or any parent thereof) is currently exported to fred. It won't be. see if /a/b/c has the same dev/ino as the file handle. It wont. use the dev/ino for /a assuming it is right. It won't be.
Then it gives a NFSEXP_NEGATIVE export for /a to the kernel.
fred timesout and resends. knfsd will look for an export entry for client fred, referring to dev/ino of /a/b, and wont find one, so we go around the loop again.
So maybe you can see how I wonder at your usage of the verb "fixed".
Maybe we should have a bit of discussion (in nfs-devel) about whether this is all a good idea, what filehandles should look-like in order to support it best, whether the up-call should use RPC (as solaris does) and related issues before we flail around with too much alpha-quality code. There are other bits of knfsd that need some work first, such as the filehandle->dentry mapping and the issue of whether filehandles really need to contain the inode number of the parent.
NeilBrown
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |