"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/