Re: knfsd 1.5 is released

David Woodhouse (David.Woodhouse@mvhi.com)
Thu, 07 Oct 1999 10:14:30 +0100


neilb@cse.unsw.edu.au said:
> 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.

I think we should ditch the negative export completely - it was a bad idea in
the first place. (I'm allowed to say that without any attempt at diplomacy - it
was my idea.)

We can pass the whole request up to mountd, and if it's to be refused, then
mountd can change the rq_proc to a special procedure which always returns
ESTALE. After making the decision, be it either yes or no, mountd just sticks
the request back in the kernel's incoming request queue, using the logic that
Olaf posted a couple of days ago. Then it either gets honoured, or just passes
directly through to the ESTALE procedure.

I don't think any change in the filehandle should be necessary with this
approach. Neither do I think it's necessary, or useful, to use RPC for the
upcall. The netlink device provides exactly the functionality that we require
with minimal overhead.

> 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.

True, but this issue is the one that kept biting me with the highest
frequency, so it's what I started working on.

I'm aware that in Linux development, handwaving is generally ignored, so I
took a couple of days to throw together a quick example of what I wanted to
do. It wasn't my intention for it to get merged into HJ's release so quickly -
I just wanted people to listen when I said 'we should do it like _this_'.

Until we _have_ sorted out the problems with my approach, unless we can do so
fairly promptly, it might be appropriate to revert those changes, or to
declare that the 1.5 branch is a development branch, and continue to maintain
the 1.4 branch in parallel.

---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.

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