Messages in this thread | | | Subject | Re: knfsd 1.5 is released | Date | Thu, 07 Oct 1999 10:14:30 +0100 | From | David Woodhouse <> |
| |
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/
| |