intent patches

Trond Myklebust (trond.myklebust@fys.uio.no)
Mon, 26 May 2003 00:31:46 +0200


>>>>> " " == Peter Braam <braam@clusterfs.com> writes:

> We _do_ have resources to sort it all out very agressively in
> the next few weeks.

Good. Let's do that...

> We currently use intents for two methods:
> - getattr
> - open
> For other methods, we would like the intents also, but they did
> not solve all our woes. We may have overlooked one or two,
> like permission.

Permission provides a pretty major source of optimization as far as
NFS is concerned: we can ignore it for all operations *except* open(),
and cached lookup().

> We introduced lookup2 and d_revalidate2 to avoid changing all
> file systems and in 2.5 we give them a namei data parameter.

Is this really desirable? It makes maintenance easy when you are
making add-on patches for the kernel, but IMHO it otherwise just makes
for a confusing interface.

> We would like to pass a pointer to nameidata to:

> - open (file method)
> - create directory (inode method)
> - lookup (inode method)
> - revalidate (dentry method)

All those are good as far as I'm concerned.

> - revalidate (inode method)

That's no longer in 2.5.x. Do you perhaps mean the new getattr()?

> and perhaps also to mkdir, rmdir, unlink, rename, mknod,
> setattr.

setattr() may help for NFSv4 where we can do open(O_TRUNC) atomically
on the server, and could optimize away the truncation.

The other ops aren't really prime candidates for optimization,
although we could possibly plonk the lookup+op into a single RPC call
by means of the COMPOUND call (again NFSv4 only).

> We have not done so yet, and can work aroud this by adding a
> field
> struct lookup_intent *d_it
> in a dentry. This is not elegant, and the protection of this
> field is delicate, but avoids large scale api changes.

Hmmm...

> Trond changes all callers instead of adding lookup2 (better
> long term, very invasive for pre-2.6)

We could mitigate the effects by making the nameidata field an
optional one. Of course, that would make it harder to add support for
credentials.

> he has vfsintent point to nameidata and inside "opendata" and
> we have the exact opposite...

Swapping will fail to offend any deeply held religious beliefs of
mine. No problems there...

> We do all methods.

Yep. As you can see I've looked only at those methods that are known
to have the largest impact w.r.t. the NFS client.

Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/