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.
?????? 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.
Signed-off-by: Benny Halevy <[email protected]>
---
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