[PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]

Over the last new months, I've been getting beaten up
about the fact the Fedora Core clients (FC5 and FC6)
no loner works with Tru64 server. The problem is
accessing mounted directories would fail with -ENOTDIR.
Similar to:

# ls /mnt/alpha/doc
/bin/ls: cannot open directory /mnt/alpha/doc: Not a directory

After months of floundering around looking at ethereal
traces and such, I actually was able to trace down a
Tru64 server to test against (thanks you very much HP!).

Low and behold... it turns not to be a Linux client
bug at all... but only Linux clients failed because
they seem to actually care what fsids are being returned.

The problem is this: Tru64 server exporting Advfs fileystems
return sign extend fsids in most but not all NFS procedures.

Meaning most fattrs returned by the server have a fsid of:
     fsid: 0xffffffff8419f8d5

but in some procs (like READDIRPLUS) the fsid is
     fsid: 0x000000008419f8d5

Which is _clearly_ wrong and does not happen with UFS
exports on the same server.

So its my contention that Tru64 has been broken forever
since only Linux clients fail, which started due to the
following patch that went into 2.6.12:

commit 55a975937d40cac582e981ddc8ed783b3dcc043c
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jun 9 09:34:19 2006 -0400

   NFS: Ensure the client submounts, when it crosses a server mountpoint.

In this patch, fsids are compared to the first fsid that was received
during the mount ala:

@ -877,6 +883,11 @@ nfs_fhget(struct super_block *sb, struct nfs_fh *fh, 
struct
     if (nfs_server_capable(inode, NFS_CAP_READDIRPLUS)
         && fattr->size <= NFS_LIMIT_READDIRPLUS)
            set_bit(NFS_INO_ADVISE_RDPLUS, &NFS_FLAGS(inode)
+          /* Deal with crossing mountpoints */
+          if (!nfs_fsid_equal(&NFS_SB(sb)->fsid, &fattr->fsid)) {
+               inode->i_op = &nfs_mountpoint_inode_operations;
+               inode->i_fop = NULL;
+          }
(Although its a bit different in today kernel) setting i_op to
nfs_mountpoint_inode_operations causes lookups to fail with
ENOTDIR in __link_path_walk() due the following check:

     if (lookup_flags & LOOKUP_DIRECTORY) {
         err = -ENOTDIR;
         if (!inode->i_op || !inode->i_op->lookup)
             break;
     }
since i_op->lookup == NULL in the nfs_mountpoint_inode_operations
structure.

Now it must be the case that only Linux clients do this type of cross
mount checking since it appears other clients don't seem to
fail in a similar fashion (at least I have not heard of any).

So the question is what to do....

Now it's a well know fact that Tru64 is on its death bed which means
its in maintenance mode and the chances of it getting fixed are slim
to none... And one could argue, that since Linux clients once did
at one time worked with Tru64 servers and only the Linux client have
changed, the Linux client should make some effort to once again
interoperable with these types servers.  I personally don't agree with
this, one should never fix client for a broken server.... but... in my
world these type of problems are called regressions... So,
unfortunately, I need to do anything and everything (with reason) to
fix these types of problems...

So with that said... attached is that patch that does indeed
fix this problem. As the comments states, the received fsid
is signed extend and then is rechecked after the first
comparison fails.


I hopeful this will be accept...

steved.


[-- Attachment #2: linux-2.6.18-nfs-Tru64-hack.patch --]
[-- Type: text/x-patch, Size: 1440 bytes --]


Deal with broken Tru64 servers that send different fsids
(due to sign extensions) by sign extending the received
fsid and then doing the comparison.

Signed-off-by: Steve Dickson <steved@redhat.com>
Acked-by: Peter Staubach <staubach@redhat.com>

--- linux-2.6.18.i686/include/linux/nfs_xdr.h.orig	2007-03-05 11:13:35.000000000 -0500
+++ linux-2.6.18.i686/include/linux/nfs_xdr.h	2007-03-05 13:23:00.000000000 -0500
@@ -21,10 +21,26 @@ struct nfs_fsid {
 
 /*
  * Helper for checking equality between 2 fsids.
+ * Hack Alert:
+ * Due do broken Tru64 servers sending sign extend
+ * 32bit fsids in most but _not_ all procedures, 
+ * we need to be a bit clever as well as make an 
+ * assumption when comparing fsids.
+ *
+ * If the assumption can be made that the bottom 32 bits 
+ * of an fsids will *always* change when the fsid changes
+ * then it should be safe to only look at the bottom 32 bits
+ * during a 64bit comparison.
+ *
+ * So by sign extending the fsid we just received (i.e. b->major) 
+ * and then do the comparison, we are still going a 64bit
+ * comparison but only really "looking at" the bottom 32 bits.
  */
 static inline int nfs_fsid_equal(const struct nfs_fsid *a, const struct nfs_fsid *b)
 {
-	return a->major == b->major && a->minor == b->minor;
+	return (a->major == b->major || 
+	    a->major == (uint64_t)((int64_t)((int32_t)(b->major & 0xffffffff)))) &&
+		a->minor == b->minor;
 }
 
 struct nfs_fattr {

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Trond Myklebust]

On Mon, 2007-03-05 at 15:35 -0500, Steve Dickson wrote:
> Over the last new months, I've been getting beaten up
> about the fact the Fedora Core clients (FC5 and FC6)
> no loner works with Tru64 server. The problem is
> accessing mounted directories would fail with -ENOTDIR.
> Similar to:
> 
> # ls /mnt/alpha/doc
> /bin/ls: cannot open directory /mnt/alpha/doc: Not a directory
> 
> After months of floundering around looking at ethereal
> traces and such, I actually was able to trace down a
> Tru64 server to test against (thanks you very much HP!).
> 
> Low and behold... it turns not to be a Linux client
> bug at all... but only Linux clients failed because
> they seem to actually care what fsids are being returned.
> 
> The problem is this: Tru64 server exporting Advfs fileystems
> return sign extend fsids in most but not all NFS procedures.
> 
> Meaning most fattrs returned by the server have a fsid of:
>      fsid: 0xffffffff8419f8d5
> 
> but in some procs (like READDIRPLUS) the fsid is
>      fsid: 0x000000008419f8d5
> 
> Which is _clearly_ wrong and does not happen with UFS
> exports on the same server.
> 
> So its my contention that Tru64 has been broken forever
> since only Linux clients fail, which started due to the
> following patch that went into 2.6.12:

Sorry, but I really do not like the idea of fixing server bugs in the
Linux client, and particularly not in generic code like this.

As far as I understood, this was a direct consequence of using the
32bitclients export option to work around the old issues with 64-bit
cookies on readdir. Is there really a need for this option now that
we've ensured that readdir cookies are no longer exported to userland?

Cheers
  Trond

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Peter Staubach]

Trond Myklebust wrote:
> On Mon, 2007-03-05 at 15:35 -0500, Steve Dickson wrote:
>   
>> Over the last new months, I've been getting beaten up
>> about the fact the Fedora Core clients (FC5 and FC6)
>> no loner works with Tru64 server. The problem is
>> accessing mounted directories would fail with -ENOTDIR.
>> Similar to:
>>
>> # ls /mnt/alpha/doc
>> /bin/ls: cannot open directory /mnt/alpha/doc: Not a directory
>>
>> After months of floundering around looking at ethereal
>> traces and such, I actually was able to trace down a
>> Tru64 server to test against (thanks you very much HP!).
>>
>> Low and behold... it turns not to be a Linux client
>> bug at all... but only Linux clients failed because
>> they seem to actually care what fsids are being returned.
>>
>> The problem is this: Tru64 server exporting Advfs fileystems
>> return sign extend fsids in most but not all NFS procedures.
>>
>> Meaning most fattrs returned by the server have a fsid of:
>>      fsid: 0xffffffff8419f8d5
>>
>> but in some procs (like READDIRPLUS) the fsid is
>>      fsid: 0x000000008419f8d5
>>
>> Which is _clearly_ wrong and does not happen with UFS
>> exports on the same server.
>>
>> So its my contention that Tru64 has been broken forever
>> since only Linux clients fail, which started due to the
>> following patch that went into 2.6.12:
>>     
>
> Sorry, but I really do not like the idea of fixing server bugs in the
> Linux client, and particularly not in generic code like this.
>
> As far as I understood, this was a direct consequence of using the
> 32bitclients export option to work around the old issues with 64-bit
> cookies on readdir. Is there really a need for this option now that
> we've ensured that readdir cookies are no longer exported to userland?

Just to be clear, you are proposing to remove the "32bitclients"
export option from the export options on the deployed Tru64 server?

A potential issue that I could see would be if there are other NFS
clients, who do need that export option used in order to interoperate
with this server.

It is an ickey idea and the right way is to fix the Tru64 server, but
given that we probably can't get it fixed, this seems relatively low
risk.

It also wouldn't be the first time (or last probably :-) ) that we've
worked around a bug in another implementation that should rightly
have been fixed in that other implementation.  :-)

       ps

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Dan Goetzman]

[-- Attachment #1: Type: text/html, Size: 3594 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Trond Myklebust]

On Mon, 2007-03-05 at 16:46 -0500, Peter Staubach wrote:
> It is an ickey idea and the right way is to fix the Tru64 server, but
> given that we probably can't get it fixed, this seems relatively low
> risk.

I disagree. The fact that people are using the fsid in creative ways, is
reason enough to be cautious about quick fixes. If we really must work
around on the client, then I'd prefer something like a mount option that
just causes us to ignore fsid changes (i.e. fall back to the 2.4.x
behaviour).

Hacking the fsid on behalf of the server is certainly vetoed.

Cheers
  Trond

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Peter Staubach]

Trond Myklebust wrote:
> On Mon, 2007-03-05 at 16:46 -0500, Peter Staubach wrote:
>   
>> It is an ickey idea and the right way is to fix the Tru64 server, but
>> given that we probably can't get it fixed, this seems relatively low
>> risk.
>>     
>
> I disagree. The fact that people are using the fsid in creative ways, is
> reason enough to be cautious about quick fixes. If we really must work
> around on the client, then I'd prefer something like a mount option that
> just causes us to ignore fsid changes (i.e. fall back to the 2.4.x
> behaviour).
>
> Hacking the fsid on behalf of the server is certainly vetoed.

Well, I find it a little hard to imagine that anyone would choose
a combination of fsids which would cause this to do the wrong thing,
but okay.  It is definitely a heuristic and thus, subject to possible
failure, no matter how remote.

Perhaps the right thing to do is to revert the NFSv2/NFSv3 support
completely and not have them worry about changing fsids?  The common
practice is to use an automounting facility or static mounts to
construct namespaces for NFSv2/NFSv3 networks.  It is really only
with the advent of NFSv4 that the fsids actually become interesting
and something that the client needs to be aware of.

Or we could just punt and document that READDIRPLUS must be disabled
on all Tru64 NFS servers if this problem is seen.

    Thanx...

       ps

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1588 bytes --]

On Mon, 5 Mar 2007, Peter Staubach wrote:

> > Hacking the fsid on behalf of the server is certainly vetoed.
> 
> Well, I find it a little hard to imagine that anyone would choose
> a combination of fsids which would cause this to do the wrong thing,
> but okay.  It is definitely a heuristic and thus, subject to possible
> failure, no matter how remote.

The different userspace servers, such as unfs3, often uses non-obvious 
fsid:s and fileid:s. Modern versions of unfs3 uses "real" fsid:s on UNIX, 
but hashed fsid:s on Windows. 


> Perhaps the right thing to do is to revert the NFSv2/NFSv3 support
> completely and not have them worry about changing fsids?  The common
> practice is to use an automounting facility or static mounts to
> construct namespaces for NFSv2/NFSv3 networks.  It is really only
> with the advent of NFSv4 that the fsids actually become interesting
> and something that the client needs to be aware of.

I disagree. This new support for mount point crossing is wonderful. It's 
very useful with unfs3, since it allows for re-exporting file systems in a 
very nice way. It's not just for NFSv4. 


> Or we could just punt and document that READDIRPLUS must be disabled
> on all Tru64 NFS servers if this problem is seen.

Sounds like a much better solution. I agree with Trond; we shouldn't fix 
server bugs in the client, and certainly not if this means less 
functionality.

Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Trond Myklebust]

On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
> Perhaps the right thing to do is to revert the NFSv2/NFSv3 support
> completely and not have them worry about changing fsids?  The common
> practice is to use an automounting facility or static mounts to
> construct namespaces for NFSv2/NFSv3 networks.  It is really only
> with the advent of NFSv4 that the fsids actually become interesting
> and something that the client needs to be aware of.

That is not quite true. It has been a problem on NFSv2/v3 ever since
IRIX introduced the 'nohide' export option (which was later copied by
the Linux server). There are only too many programs out there that are
easily fooled by the combination of hard links and non-unique inode
numbers.

> Or we could just punt and document that READDIRPLUS must be disabled
> on all Tru64 NFS servers if this problem is seen.

That would also be an option.

Cheers
  Trond

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

Trond Myklebust wrote:
> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>> Or we could just punt and document that READDIRPLUS must be disabled
>> on all Tru64 NFS servers if this problem is seen.
> 
> That would also be an option.
Assuming there is a way to turn off READDIRPLUS  on the
server side... I'll look into it... Or are you suggesting
that we have a mount option to turn off READDIRPLUS on the
client side? (Note: I believe other implementations have
this mount option if that means anything)....

steved.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]



Steve Dickson wrote:
> 
> Trond Myklebust wrote:
>> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>>> Or we could just punt and document that READDIRPLUS must be disabled
>>> on all Tru64 NFS servers if this problem is seen.
>> That would also be an option.
> Assuming there is a way to turn off READDIRPLUS  on the
> server side... I'll look into it... Or are you suggesting
> that we have a mount option to turn off READDIRPLUS on the
> client side? (Note: I believe other implementations have
> this mount option if that means anything)....
Not too surprising, there does not seem to be away to
disable READDIRPLUS on the server side.... so...
Since it was incredibly easy to disable READDIRPLUS
from the client side... I went ahead came up and tested
the attached patches...

Again, I believe there are other implementations, like Apple,
that have this type of knob so in the end, this might be
a good thing to have in general... It definitely helps with
broken Tru64 servers...  So please consider...

tia,

steved.

[-- Attachment #2: linux-2.6.20-nfs-nordirplus.patch --]
[-- Type: text/x-patch, Size: 1529 bytes --]

Added support to turn off the NFSv3 READDIRPLUS RPC.

Signed-off-by: Steve Dickson <steved@redhat.com>

----------------------------------------------
--- linux-2.6.20.i686/fs/nfs/super.c.orig	2007-03-05 11:26:41.130885000 -0500
+++ linux-2.6.20.i686/fs/nfs/super.c	2007-03-06 16:10:13.390550000 -0500
@@ -291,6 +291,7 @@
 		{ NFS_MOUNT_NOAC, ",noac", "" },
 		{ NFS_MOUNT_NONLM, ",nolock", "" },
 		{ NFS_MOUNT_NOACL, ",noacl", "" },
+		{ NFS_MOUNT_NORDIRPLUS, ",nordirplus", "" },
 		{ 0, NULL, NULL }
 	};
 	const struct proc_nfs_info *nfs_infop;
--- linux-2.6.20.i686/fs/nfs/client.c.orig	2007-03-05 11:26:40.995885000 -0500
+++ linux-2.6.20.i686/fs/nfs/client.c	2007-03-06 11:07:23.208538000 -0500
@@ -618,7 +618,8 @@
 	if (clp->cl_nfsversion == 3) {
 		if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
 			server->namelen = NFS3_MAXNAMLEN;
-		server->caps |= NFS_CAP_READDIRPLUS;
+		if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
+			server->caps |= NFS_CAP_READDIRPLUS;
 	} else {
 		if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
 			server->namelen = NFS2_MAXNAMLEN;
--- linux-2.6.20.i686/include/linux/nfs_mount.h.orig	2007-02-04 13:44:54.000000000 -0500
+++ linux-2.6.20.i686/include/linux/nfs_mount.h	2007-03-06 10:59:06.457362000 -0500
@@ -61,6 +61,7 @@
 #define NFS_MOUNT_NOACL		0x0800	/* 4 */
 #define NFS_MOUNT_STRICTLOCK	0x1000	/* reserved for NFSv4 */
 #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
+#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
 #define NFS_MOUNT_FLAGMASK	0xFFFF
 
 #endif

[-- Attachment #3: nfs-utils-1.0.12-mount-nordirplus.patch --]
[-- Type: text/x-patch, Size: 1796 bytes --]

Adds the -o nordirplus mount option that will disable 
NFS clients from using the READDIRPLUS RPC.

Signed-off-by: Steve Dickson <steved@redhat.com>

------------------------------
--- nfs-utils-1.0.12/utils/mount/nfs_mount.h.orig	2007-03-06 15:41:19.557090000 -0500
+++ nfs-utils-1.0.12/utils/mount/nfs_mount.h	2007-03-06 15:44:22.888922000 -0500
@@ -63,6 +63,7 @@
 #define NFS_MOUNT_BROKEN_SUID	0x0400	/* 4 */
 #define NFS_MOUNT_NOACL     0x0800  /* 4 */
 #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
+#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
 
 /* security pseudoflavors */
 
--- nfs-utils-1.0.12/utils/mount/nfsmount.c.orig	2007-03-06 15:41:19.582094000 -0500
+++ nfs-utils-1.0.12/utils/mount/nfsmount.c	2007-03-06 15:44:53.509748000 -0500
@@ -788,6 +788,10 @@
 				data->flags &= ~NFS_MOUNT_NOACL;
 				if (!val)
 					data->flags |= NFS_MOUNT_NOACL;
+			} else if (!strcmp(opt, "rdirplus")) {
+				data->flags &= ~NFS_MOUNT_NORDIRPLUS;
+				if (!val)
+					data->flags |= NFS_MOUNT_NORDIRPLUS;
 #endif
 			} else {
 			bad_option:
@@ -975,6 +979,7 @@
 #endif
 #if NFS_MOUNT_VERSION >= 5
 	printf("sec = %u ", data.pseudoflavor);
+	printf("readdirplus = %d ", (data.flags & NFS_MOUNT_NORDIRPLUS) != 0);
 #endif
 	printf("\n");
 #endif
--- nfs-utils-1.0.12/utils/mount/nfs.man.orig	2007-03-06 15:41:19.431090000 -0500
+++ nfs-utils-1.0.12/utils/mount/nfs.man	2007-03-06 16:06:29.487656000 -0500
@@ -272,6 +272,11 @@
 .I udp
 Mount the NFS filesystem using the UDP protocol.  This
 is the default.
+.TP 1.5i
+.I nordirplus
+Disables NFSv3 READDIRPLUS RPCs. Use this options when
+mounting servers that don't support or have broken
+READDIRPLUS implementations.
 .P
 All of the non-value options have corresponding nooption forms.
 For example, nointr means don't allow file operations to be

[-- Attachment #4: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #5: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Talpey, Thomas]

The current code already supports disabling READDIRPLUS to
servers that don't support it. It happens after the first bad
response. The intentional option is a good idea for other
reasons though, huge directories yield huge attributes.

One problem I see with the mount option is that it might be
silently ignored by old mount binaries. That will confuse users
who install a new kernel and don't update util-linux/nfs-utils.

Tom.

At 04:42 PM 3/6/2007, Steve Dickson wrote:
>
>
>Steve Dickson wrote:
>> 
>> Trond Myklebust wrote:
>>> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>>>> Or we could just punt and document that READDIRPLUS must be disabled
>>>> on all Tru64 NFS servers if this problem is seen.
>>> That would also be an option.
>> Assuming there is a way to turn off READDIRPLUS  on the
>> server side... I'll look into it... Or are you suggesting
>> that we have a mount option to turn off READDIRPLUS on the
>> client side? (Note: I believe other implementations have
>> this mount option if that means anything)....
>Not too surprising, there does not seem to be away to
>disable READDIRPLUS on the server side.... so...
>Since it was incredibly easy to disable READDIRPLUS
>from the client side... I went ahead came up and tested
>the attached patches...
>
>Again, I believe there are other implementations, like Apple,
>that have this type of knob so in the end, this might be
>a good thing to have in general... It definitely helps with
>broken Tru64 servers...  So please consider...
>
>tia,
>
>steved.
>
>Added support to turn off the NFSv3 READDIRPLUS RPC.
>
>Signed-off-by: Steve Dickson <steved@redhat.com>
>
>----------------------------------------------
>--- linux-2.6.20.i686/fs/nfs/super.c.orig	2007-03-05 11:26:41.130885000 -0500
>+++ linux-2.6.20.i686/fs/nfs/super.c	2007-03-06 16:10:13.390550000 -0500
>@@ -291,6 +291,7 @@
> 		{ NFS_MOUNT_NOAC, ",noac", "" },
> 		{ NFS_MOUNT_NONLM, ",nolock", "" },
> 		{ NFS_MOUNT_NOACL, ",noacl", "" },
>+		{ NFS_MOUNT_NORDIRPLUS, ",nordirplus", "" },
> 		{ 0, NULL, NULL }
> 	};
> 	const struct proc_nfs_info *nfs_infop;
>--- linux-2.6.20.i686/fs/nfs/client.c.orig	2007-03-05 11:26:40.995885000 -0500
>+++ linux-2.6.20.i686/fs/nfs/client.c	2007-03-06 11:07:23.208538000 -0500
>@@ -618,7 +618,8 @@
> 	if (clp->cl_nfsversion == 3) {
> 		if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
> 			server->namelen = NFS3_MAXNAMLEN;
>-		server->caps |= NFS_CAP_READDIRPLUS;
>+		if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
>+			server->caps |= NFS_CAP_READDIRPLUS;
> 	} else {
> 		if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
> 			server->namelen = NFS2_MAXNAMLEN;
>--- linux-2.6.20.i686/include/linux/nfs_mount.h.orig	2007-02-04 
>13:44:54.000000000 -0500
>+++ linux-2.6.20.i686/include/linux/nfs_mount.h	2007-03-06 
>10:59:06.457362000 -0500
>@@ -61,6 +61,7 @@
> #define NFS_MOUNT_NOACL		0x0800	/* 4 */
> #define NFS_MOUNT_STRICTLOCK	0x1000	/* reserved for NFSv4 */
> #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
>+#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
> #define NFS_MOUNT_FLAGMASK	0xFFFF
> 
> #endif
>
>Adds the -o nordirplus mount option that will disable 
>NFS clients from using the READDIRPLUS RPC.
>
>Signed-off-by: Steve Dickson <steved@redhat.com>
>
>------------------------------
>--- nfs-utils-1.0.12/utils/mount/nfs_mount.h.orig	2007-03-06 
>15:41:19.557090000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfs_mount.h	2007-03-06 
>15:44:22.888922000 -0500
>@@ -63,6 +63,7 @@
> #define NFS_MOUNT_BROKEN_SUID	0x0400	/* 4 */
> #define NFS_MOUNT_NOACL     0x0800  /* 4 */
> #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
>+#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
> 
> /* security pseudoflavors */
> 
>--- nfs-utils-1.0.12/utils/mount/nfsmount.c.orig	2007-03-06 
>15:41:19.582094000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfsmount.c	2007-03-06 15:44:53.509748000 -0500
>@@ -788,6 +788,10 @@
> 				data->flags &= ~NFS_MOUNT_NOACL;
> 				if (!val)
> 					data->flags |= NFS_MOUNT_NOACL;
>+			} else if (!strcmp(opt, "rdirplus")) {
>+				data->flags &= ~NFS_MOUNT_NORDIRPLUS;
>+				if (!val)
>+					data->flags |= NFS_MOUNT_NORDIRPLUS;
> #endif
> 			} else {
> 			bad_option:
>@@ -975,6 +979,7 @@
> #endif
> #if NFS_MOUNT_VERSION >= 5
> 	printf("sec = %u ", data.pseudoflavor);
>+	printf("readdirplus = %d ", (data.flags & NFS_MOUNT_NORDIRPLUS) != 0);
> #endif
> 	printf("\n");
> #endif
>--- nfs-utils-1.0.12/utils/mount/nfs.man.orig	2007-03-06 
>15:41:19.431090000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfs.man	2007-03-06 16:06:29.487656000 -0500
>@@ -272,6 +272,11 @@
> .I udp
> Mount the NFS filesystem using the UDP protocol.  This
> is the default.
>+.TP 1.5i
>+.I nordirplus
>+Disables NFSv3 READDIRPLUS RPCs. Use this options when
>+mounting servers that don't support or have broken
>+READDIRPLUS implementations.
> .P
> All of the non-value options have corresponding nooption forms.
> For example, nointr means don't allow file operations to be
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>NFS maillist  -  NFS@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/nfs


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 394 bytes --]

On Tue, 6 Mar 2007, Steve Dickson wrote:

>+               { NFS_MOUNT_NORDIRPLUS, ",nordirplus", "" },

I prefer the option name "noreaddirplus". It's only 3 chars longer, but 
that's a small price to pay for avoiding confusion etc. 

Regards, 
---
Peter Ã…strand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

Talpey, Thomas wrote:
> The current code already supports disabling READDIRPLUS to
> servers that don't support it. It happens after the first bad
> response. The intentional option is a good idea for other
> reasons though, huge directories yield huge attributes.
Yes... I agree this could be useful in other applications...

> 
> One problem I see with the mount option is that it might be
> silently ignored by old mount binaries. That will confuse users
> who install a new kernel and don't update util-linux/nfs-utils.
The problem is not so much old mount binaries, since they will fail
with something similar to "Unsupported nfs mount option: nordirplus",
its using new mount binaries with old kernels. The kernels
will silently ignore the option. One could tell the option is
not set by catting /proc/mounts (since the "nordirplus" would
not exist), but I agree there is potential for confusion...

But on he other hand I didn't want to increase the mount
version from 5 to 6 since I think that whole mounting version
stuff is just rats nest.. and Two, I really didn't mounts
to start failing (due to mis-versioning) for a option that
will probably never be used... But it is trivial to increase
the version, but it just causes so many headaches I was
trying to avoid it... Right or wrong that was the reasoning...

steved.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

CgpQZXRlciDDhXN0cmFuZCB3cm90ZToKPiBPbiBUdWUsIDYgTWFyIDIwMDcsIFN0ZXZlIERpY2tz
b24gd3JvdGU6Cj4gCj4+ICsgICAgICAgICAgICAgICB7IE5GU19NT1VOVF9OT1JESVJQTFVTLCAi
LG5vcmRpcnBsdXMiLCAiIiB9LAo+IAo+IEkgcHJlZmVyIHRoZSBvcHRpb24gbmFtZSAibm9yZWFk
ZGlycGx1cyIuIEl0J3Mgb25seSAzIGNoYXJzIGxvbmdlciwgYnV0IAo+IHRoYXQncyBhIHNtYWxs
IHByaWNlIHRvIHBheSBmb3IgYXZvaWRpbmcgY29uZnVzaW9uIGV0Yy4KVGhlIHJlYXNvbiBJIHVz
ZWQgJ25vcmRpcnBsdXMnIHdhcyBiZWNhdXNlIEFwcGxlIHVzZXMgdGhvc2UgY2hhcmFjdGVycwph
bmQgSSB0aG91Z2h0IGl0IGJlIGEgZ29vZCBJIGRpZCB0byB0cnkgYW5kIGtlZXAgdGhpbmdzIGNv
bnNpc3RlbnQuCkJ1dCBpbiB0aGUgZW5kLCBJIGNvdWxkIGNhcmVsZXNzIHdoYXQgd2UgY2FsbCB0
aGUgb3B0aW9uIGFzIGxvbmcKYXMgdGhlIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUuLi4KCnN0ZXZl
ZC4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0
aGUgRnV0dXJlIG9mIElUCkpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQg
eW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKb3BpbmlvbnMgb24gSVQgJiBidXNp
bmVzcyB0b3BpY3MgdGhyb3VnaCBicmllZiBzdXJ2ZXlzLWFuZCBlYXJuIGNhc2gKaHR0cDovL3d3
dy50ZWNoc2F5LmNvbS9kZWZhdWx0LnBocD9wYWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lE
PURFVkRFVgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpO
RlMgbWFpbGxpc3QgIC0gIE5GU0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5z
b3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbmZzCg==

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 5838 bytes --]

A comment...

You've implemented a "negative" -- the usual convention is to implement 
the "positive" option.   This is how Apple/*BSD do it for READDIRPLUS, 
and it might be good to follow existing precedent.

I think you should implement "rddirplus" and make it the default.  That 
way you get "norddirplus" automatically.

You should also include appropriate man page changes in your patch. ;-D

Steve Dickson wrote:
> 
> 
> Steve Dickson wrote:
>>
>> Trond Myklebust wrote:
>>> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>>>> Or we could just punt and document that READDIRPLUS must be disabled
>>>> on all Tru64 NFS servers if this problem is seen.
>>> That would also be an option.
>> Assuming there is a way to turn off READDIRPLUS  on the
>> server side... I'll look into it... Or are you suggesting
>> that we have a mount option to turn off READDIRPLUS on the
>> client side? (Note: I believe other implementations have
>> this mount option if that means anything)....
> Not too surprising, there does not seem to be away to
> disable READDIRPLUS on the server side.... so...
> Since it was incredibly easy to disable READDIRPLUS
> from the client side... I went ahead came up and tested
> the attached patches...
> 
> Again, I believe there are other implementations, like Apple,
> that have this type of knob so in the end, this might be
> a good thing to have in general... It definitely helps with
> broken Tru64 servers...  So please consider...
> 
> tia,
> 
> steved.
> 
> 
> ------------------------------------------------------------------------
> 
> Added support to turn off the NFSv3 READDIRPLUS RPC.
> 
> Signed-off-by: Steve Dickson <steved@redhat.com>
> 
> ----------------------------------------------
> --- linux-2.6.20.i686/fs/nfs/super.c.orig	2007-03-05 11:26:41.130885000 -0500
> +++ linux-2.6.20.i686/fs/nfs/super.c	2007-03-06 16:10:13.390550000 -0500
> @@ -291,6 +291,7 @@
>  		{ NFS_MOUNT_NOAC, ",noac", "" },
>  		{ NFS_MOUNT_NONLM, ",nolock", "" },
>  		{ NFS_MOUNT_NOACL, ",noacl", "" },
> +		{ NFS_MOUNT_NORDIRPLUS, ",nordirplus", "" },
>  		{ 0, NULL, NULL }
>  	};
>  	const struct proc_nfs_info *nfs_infop;
> --- linux-2.6.20.i686/fs/nfs/client.c.orig	2007-03-05 11:26:40.995885000 -0500
> +++ linux-2.6.20.i686/fs/nfs/client.c	2007-03-06 11:07:23.208538000 -0500
> @@ -618,7 +618,8 @@
>  	if (clp->cl_nfsversion == 3) {
>  		if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
>  			server->namelen = NFS3_MAXNAMLEN;
> -		server->caps |= NFS_CAP_READDIRPLUS;
> +		if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
> +			server->caps |= NFS_CAP_READDIRPLUS;
>  	} else {
>  		if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
>  			server->namelen = NFS2_MAXNAMLEN;
> --- linux-2.6.20.i686/include/linux/nfs_mount.h.orig	2007-02-04 13:44:54.000000000 -0500
> +++ linux-2.6.20.i686/include/linux/nfs_mount.h	2007-03-06 10:59:06.457362000 -0500
> @@ -61,6 +61,7 @@
>  #define NFS_MOUNT_NOACL		0x0800	/* 4 */
>  #define NFS_MOUNT_STRICTLOCK	0x1000	/* reserved for NFSv4 */
>  #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
> +#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
>  #define NFS_MOUNT_FLAGMASK	0xFFFF
>  
>  #endif
> 
> 
> ------------------------------------------------------------------------
> 
> Adds the -o nordirplus mount option that will disable 
> NFS clients from using the READDIRPLUS RPC.
> 
> Signed-off-by: Steve Dickson <steved@redhat.com>
> 
> ------------------------------
> --- nfs-utils-1.0.12/utils/mount/nfs_mount.h.orig	2007-03-06 15:41:19.557090000 -0500
> +++ nfs-utils-1.0.12/utils/mount/nfs_mount.h	2007-03-06 15:44:22.888922000 -0500
> @@ -63,6 +63,7 @@
>  #define NFS_MOUNT_BROKEN_SUID	0x0400	/* 4 */
>  #define NFS_MOUNT_NOACL     0x0800  /* 4 */
>  #define NFS_MOUNT_SECFLAVOUR	0x2000	/* 5 */
> +#define NFS_MOUNT_NORDIRPLUS	0x4000	/* 5 */
>  
>  /* security pseudoflavors */
>  
> --- nfs-utils-1.0.12/utils/mount/nfsmount.c.orig	2007-03-06 15:41:19.582094000 -0500
> +++ nfs-utils-1.0.12/utils/mount/nfsmount.c	2007-03-06 15:44:53.509748000 -0500
> @@ -788,6 +788,10 @@
>  				data->flags &= ~NFS_MOUNT_NOACL;
>  				if (!val)
>  					data->flags |= NFS_MOUNT_NOACL;
> +			} else if (!strcmp(opt, "rdirplus")) {
> +				data->flags &= ~NFS_MOUNT_NORDIRPLUS;
> +				if (!val)
> +					data->flags |= NFS_MOUNT_NORDIRPLUS;
>  #endif
>  			} else {
>  			bad_option:
> @@ -975,6 +979,7 @@
>  #endif
>  #if NFS_MOUNT_VERSION >= 5
>  	printf("sec = %u ", data.pseudoflavor);
> +	printf("readdirplus = %d ", (data.flags & NFS_MOUNT_NORDIRPLUS) != 0);
>  #endif
>  	printf("\n");
>  #endif
> --- nfs-utils-1.0.12/utils/mount/nfs.man.orig	2007-03-06 15:41:19.431090000 -0500
> +++ nfs-utils-1.0.12/utils/mount/nfs.man	2007-03-06 16:06:29.487656000 -0500
> @@ -272,6 +272,11 @@
>  .I udp
>  Mount the NFS filesystem using the UDP protocol.  This
>  is the default.
> +.TP 1.5i
> +.I nordirplus
> +Disables NFSv3 READDIRPLUS RPCs. Use this options when
> +mounting servers that don't support or have broken
> +READDIRPLUS implementations.
>  .P
>  All of the non-value options have corresponding nooption forms.
>  For example, nointr means don't allow file operations to be
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs


[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 265 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture Linux Projects Group
email;internet:chuck dot lever at nospam oracle dot com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Peter Staubach]

Chuck Lever wrote:
> A comment...
>
> You've implemented a "negative" -- the usual convention is to 
> implement the "positive" option.   This is how Apple/*BSD do it for 
> READDIRPLUS, and it might be good to follow existing precedent.
>
> I think you should implement "rddirplus" and make it the default.  
> That way you get "norddirplus" automatically.
>
> You should also include appropriate man page changes in your patch. ;-D
>

If "rddirplus" is the option and is the default, how do you turn it off?

Actually, I am also curious why any existing precedent is interesting.
In general, none of the existing precedents have been followed in the
past...  :-)

    Thanx...

       ps

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Steve Dickson]

Chuck Lever wrote:
> You've implemented a "negative" -- the usual convention is to implement 
> the "positive" option.   This is how Apple/*BSD do it for READDIRPLUS, 
> and it might be good to follow existing precedent.
True... but I pattern it after the our 'noacl' option....
so I am following the existing precedent (using the same characters as 
Apple) but only to a point... ;-) How much precedent can one take! :-D

> 
> I think you should implement "rddirplus" and make it the default.  That 
> way you get "norddirplus" automatically.
Take a closer look... -o rdirplus is the default... and -o nordirplus
is not...
> 
> You should also include appropriate man page changes in your patch. ;-D
Maybe the man page can be worded better...

steved.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] NFS: Sign Extentions with Tru64 FSIDs.

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

Peter Staubach wrote:
> Chuck Lever wrote:
>> A comment...
>>
>> You've implemented a "negative" -- the usual convention is to 
>> implement the "positive" option.   This is how Apple/*BSD do it for 
>> READDIRPLUS, and it might be good to follow existing precedent.
>>
>> I think you should implement "rddirplus" and make it the default.  
>> That way you get "norddirplus" automatically.
>>
>> You should also include appropriate man page changes in your patch. ;-D
>>
> 
> If "rddirplus" is the option and is the default, how do you turn it off?

The way you turn off cto, lock, and intr:  by preceding it with a "no".

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 265 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture Linux Projects Group
email;internet:chuck dot lever at nospam oracle dot com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs