Subject: RE: Compound operations : NFS kernel support

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 22 Mar 2000 06:19:26 -0800

kvs sivak wrote:
>  We are trying to implement NFS v4 support in Linux
> Kernel 2.2.
> It is needed that the VFS interface be coded to
> support any required file system in Linux.Since the
> VFS looks at each operation as an independent one
> there seems to be no advantage in using Compound
> except in adding the extra processing required.

I don't know the details of the Linux VFS but there
may be cases in which you will want to compound
GETATTR with other operations, such as OPEN.  When
opening a file you are supposed to clear your data
cache if the file has been modified since the last 
time you opened it.  Doing a GETATTR compounded with
the OPEN is probably the best way to do that.

In cases where your VFS structure means that the 
information it would be convenient to get with 
COMPOUND is not required by the current operation,
you can still use caching to avoid RPC's.  If you
put the results of a GETATTR compounded with another
request in you attribute cache, it will be 
available when OS code, through the VFS, decides 
to ask for it, avoiding an RPC at that point.
Depending on the kinds of environments you are
targetting, you could extend this to other cases
in which the need for the attributes is probable
but not certain.  You could always add GETATTR
to LOOKUP on the grounds that it adds very little
cost and will often be required.  You could also
add READ to OPEN for read to get the first block 
of data and cache it.  There are lots of possibilities.
Some of them may even be desirable :-)

When latency is high, it might even be useful to
combine operations for unrelated files with an 
RPC tat you are doing anyway.  For example,
attribute and name cache entries that are being
used but are soon to time out, might be revalidated
by doing GETATTR's compounded to a totally unrelated
RPC.
 
> 
> for example the namei opreation looks up directories
> at only one level. there is no multi-component
> lookup.This would make it impossoible to use the
> multi-component lookup of NFSv4.Thus the kernel would
> request lookups only for a single component and there
> is no way to determine a full pathname that may be
> sent to the NFS server for multi-component lookup.

I don't see how you could use multi-component lookup.

> similarly for other procedures too.

For multi-component lookup, the V4 client code has no
way of knowing or effectively guessing what will be 
needed next.  In cases in which you can make a good
guess it may be possible to do operations in advance,
as long as those only interrogate file system state.
 
> Is this understanding of ours correct ?
> Are there any other means by which compound opreations
> can be used advantageously ?

I believe there are but this is just speculation.  I
think everyone is very interested to find out how useful
COMPOUND turns out to be in practice.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 22 Mar 2000 07:26:22 -0800 (PST)

> the OPEN is probably the best way to do that.

One may also want to compound OPEN with READ to get the first few bytes. This
is useful to optimize UNIX commands like "file" or GUI-based browsers that
like to show users little icons that describe the file content.

> I don't see how you could use multi-component lookup.

If kvs's client doesn't use multi-component lookup, mounts
are going to result in lots more operations. Perhaps kvs's
client will use COMPOUND to send a series of:

	LOOKUP "c1" ; LOOKUP "c2"; ... LOOKUP "cN" ; GETFH

To avoid multiple round trips.

Or perhaps the server side lookup routine could simple call namei in a loop
when it gets a multi-component lookup.

> COMPOUND turns out to be in practice.

The immediate usefulness of COMPOUND is that the any additional overheard is
made up for in streamlined code. For example file handle processing. Consider
models that export file systems to groups of hosts. In NFSv[23] one has to
extract the the file handle from one of dozens of different argument
structures.  In an NFSv4 server, extracting the current file handle is a
breeze, and so one deals with less code. The post op attribute processing is
another example, where in V3, code was needed in each client and server side
operation to deal with processing (or non-processing) of optional post of
attributes. Now it can be done in one place on the client and server. Going
back to one READDIR from two in NFSv3 is another example; cuts the code in
half. And of course COMPOUND or multi-component lookup eliminates the
MOUNT protocol. 

	-mre