nfs 4.1 server returns available file lyaout type when the file system is exported without pNFS

nfs 4.1 server returns available file lyaout type when the file system is exported without pNFS

[Lior]

Hi,

Steps to reproduce:

insert this in /etc/export on the server side:
/mnt/testnfs 
*(rw,sync,wdelay,hide,nocrossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534)

on the server side:
exportfs -ra

from client run connectathon:

The settings for connectathon are for nfs 4.1 without Pnfs ( although 
the module of: nfs_layout_nfsv41_files is loaded on the client due to 
the fact that the current clients design does not have an option of a 
module of nfs 4.1 WITHOUT pNFS)

Connectathon tests passed , but when I looked at nfsstat, I saw this ( 
relevant to Pnfs):
layoutget activity
layout return activity
(NO getdevice info activity)

(When I tried running the same , this time the server had this line in 
its /etc/exports:
/mnt/testnfs 
*(rw,sync,wdelay,hide,nocrossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,pnfs)
(NOTE: with Pnfs flag.)

connectathon tests passed , and when I looked at nfsstat, I saw this ( 
relevant to Pnfs):
layoutget activity
layoutreturn activity
getdevice info activity.)


  When we look at the logs and code, we saw that layoutget and layout 
return are sent by the client, and the server returns error messages to 
both ( as expected in regard to layoutget & layout return being sent by 
the client when the server is not pNFS enabled , BUT then again , the 
client wouldn't have sent layoutget & layout return ,originally, if it 
were to get the correct flag from the server, see Actuall behavior 
analysis below). we could also see that  there was NO getdevice info 
activity after that, and the server/client went on with regular nfs 
activity.

the no getdevice info activity was confirmed by the connectathon runs ( 
could be seen above).
expected results are:

     NO pNFS commands shown in nfsstat.
     NO pNFS module should be loaded in the client.

Actual behavior analysis
The FATTR4_FS_LAYOUT_TYPE field returned from the server, which should 
be empty, contains LAYOUT4_NFSV4_1_FILES, which causes the module to be 
loaded and the client to think pNFS is available.

Diagnosis:
This server behaviour is currently hard coded regardless of if we export 
a file system over pnfs or not. which doesn't seem right.

Re: nfs 4.1 server returns available file lyaout type when the file system is exported without pNFS (updated)

[Lior]

בתאריך 13/05/2012 15:22, ציטוט Lior:
> Hi,
>
> Steps to reproduce:
>
> insert this in /etc/export on the server side:
> /mnt/testnfs 
> *(rw,sync,wdelay,hide,nocrossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534)
>
> on the server side:
> exportfs -ra
>
> from client run connectathon:
>
> The settings for connectathon are for nfs 4.1 without Pnfs ( although 
> the module of: nfs_layout_nfsv41_files is loaded on the client due to 
> the fact that the current clients design does not have an option of a 
> module of nfs 4.1 WITHOUT pNFS)
>
> Connectathon tests passed , but when I looked at nfsstat, I saw this ( 
> relevant to Pnfs):
> layoutget activity
> layout return activity
> (NO getdevice info activity)
>
> (When I tried running the same , this time the server had this line in 
> its /etc/exports:
> /mnt/testnfs 
> *(rw,sync,wdelay,hide,nocrossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,pnfs)
> (NOTE: with Pnfs flag.)
>
> connectathon tests passed , and when I looked at nfsstat, I saw this ( 
> relevant to Pnfs):
> layoutget activity
> layoutreturn activity
> getdevice info activity.)
>
>
>  When we look at the logs and code, we saw that layoutget and layout 
> return are sent by the client, and the server returns error messages 
> to both ( as expected in regard to layoutget & layout return being 
> sent by the client when the server is not pNFS enabled , BUT then 
> again , the client wouldn't have sent layoutget & layout return 
> ,originally, if it were to get the correct flag from the server, see 
> Actuall behavior analysis below). we could also see that  there was NO 
> getdevice info activity after that, and the server/client went on with 
> regular nfs activity.
>
> the no getdevice info activity was confirmed by the connectathon runs 
> ( could be seen above).
> expected results are:
>
>     NO pNFS commands shown in nfsstat.
>     NO pNFS module should be loaded in the client.
>
> Actual behavior analysis
> The FATTR4_FS_LAYOUT_TYPE field returned from the server, which should 
> be empty, contains LAYOUT4_NFSV4_1_FILES, which causes the module to 
> be loaded and the client to think pNFS is available.
>
> Diagnosis:
> This server behaviour is currently hard coded regardless of if we 
> export a file system over pnfs or not. which doesn't seem right.
>
This was done with :

pnfsd-lexp (local export) testing
back end that exports a local file system over pnfs, playing both the MDS and a single DS
on the server.

Thanks

Lior K.

[PATCH] pnfsd: apply pnfs export option on pnfs export ops setup

[Benny Halevy]

Signed-off-by: Benny Halevy <bhalevy@tonian.com>
---
 fs/nfsd/export.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index b6e46ab..b2fa749 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -421,7 +421,7 @@ static int check_export(struct inode *inode, int *flags, unsigned char *uuid)
 		return -EINVAL;
 	}
 
-	return pnfsd_check_export(inode, flags);
+	return 0;
 }
 
 #ifdef CONFIG_NFSD_V4
@@ -624,6 +624,13 @@ static int svc_export_parse(struct cache_detail *cd, char *mesg, int mlen)
 				   exp.ex_uuid);
 		if (err)
 			goto out4;
+
+		if (exp.ex_pnfs) {
+			err = pnfsd_check_export(exp.ex_path.dentry->d_inode,
+						 &exp.ex_flags);
+			if (err)
+				goto out4;
+		}
 	}
 
 	expp = svc_export_lookup(&exp);
-- 
1.7.6.5