Subject: Compound operations : NFS kernel support

From: kvs sivak <[email-masked]>
Date: Wed, 22 Mar 2000 11:16:25 +0000 (GMT)

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

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.
similarly for other procedures too.

Is this understanding of ours correct ?
Are there any other means by which compound opreations
can be used advantageously ?

K.Sivakumar
K.V.Subramanian

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

---

From: Zachary Amsden <[email-masked]>
Date: Wed, 22 Mar 2000 15:48:59 -0800

Compound operations should be a big advantage for doing GETATTR on all files 
in a directory, or similar batch tasks.

-- 
Zachary Amsden  [email-masked]  3-6919  31-2-510  Core Protocols

---

From: Erez Zadok <[email-masked]>
Date: Thu, 23 Mar 2000 15:09:47 -0500 (EST)

>  We are trying to implement NFS v4 support in Linux

I've worked w/ several VFSs and esp. the Linux vfs since 2.0 and up to the
latest 2.3.99-pre2 (a precursor to 2.4) implementing stackable templates.  I
would suggest that you look at the latest 2.3 VFS as well, b/c it is a lot
cleaner and saner than the 2.2 one; it's also different than 2.2, requiring
some porting work for any 2.2-based file system.  It's easier to work w/ the
latest 2.3 VFS than w/ 2.2.  Also, by the time you get your NFSv4 code
stable, Linux distributions will have probably moved to 2.4.  So it's better
to pay the cost of working w/ the 2.3 VFS now, instead of doing a major port
later.

> except in adding the extra processing required.

Another good reason to work w/ 2.3 is that you might have a chance to
convince people to make VFS changes such as multi-component lookup support.
Nothing like that will go into 2.2, and if you miss your chance in 2.3,
you'll have to wait several months for 2.5 to start.

Look at linux/fs/namei.c:lookup_dentry() the 2nd argument, "base".  You
might be able to [ab]use to do multi component lookup.  There's also a
"flags" field, which might be used to create a new flag to tell this routine
to do multi-component lookup; the advantage of this would be that you won't
be changing interfaces, just adding a new flag and code that will be
triggered only for that code.

The dentry structure in the linux VFS stores the component name.  You can
use it to reconstruct full paths.  There are kernel routines such as
d_path() and other contributed code (look for dentry_get_path) which do just
that.  So you might be able to use that in your special lookup function with
the right NFS4 RPC.  Although a better implementation would not break and
then reconstruct paths---meaning a VFS change to lookup_dentry().

> can be used advantageously ?

BTW, if you have linux-VFS questions, you might consider [cross-]posting
them to the linux-fsdevel list.

> K.V.Subramanian

Good luck.

Erez.