Re: knfsd 1.5 is released

H . J . Lu (hjl@valinux.com)
Thu, 7 Oct 1999 16:32:05 -0700

On Thu, Oct 07, 1999 at 10:14:30AM +0100, David Woodhouse wrote:
>
> 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.

That sounds good.

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

I am planning to do so as soon as I get the CVS server on line. I do have some
patches for 1.4.7.

-- 
H.J. Lu (hjl@gnu.org)


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