[PATCH] CACHE: Fix test script as delegation being introduced

[PATCH] CACHE: Fix test script as delegation being introduced

[Su Yanjun]

When we run nfstest_cache with nfsversion=4, it fails.
As i know nfsv4 introduces delegation, so nfstest_cache runs fail since nfsv4.

The test commandline is as below:
 ./nfstest_cache --nfsversion=4 -e  /nfsroot --server 192.168.102.143 --client 192.168.102.142 --runtest acregmax_data --verbose all

This patch adds compatible code for nfsv3 and nfsv4.
When we test nfsv4, just use 'chmod' to recall delegation, then
run the test. As 'chmod' will modify atime, so use 'noatime' mount option.

Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
---
 test/nfstest_cache | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/test/nfstest_cache b/test/nfstest_cache
index 0838418..a31d48f 100755
--- a/test/nfstest_cache
+++ b/test/nfstest_cache
@@ -165,8 +165,13 @@ class CacheTest(TestUtil):
             fd = None
             attr = 'data' if data_cache else 'attribute'
             header = "Verify consistency of %s caching with %s on a file" % (attr, self.nfsstr())
+
             # Mount options
-            mtopts = "hard,intr,rsize=4096,wsize=4096"
+            if self.nfsversion >= 4:
+                mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
+            else: 
+                mtopts = "hard,intr,rsize=4096,wsize=4096"
+
             if actimeo:
                 header += " actimeo = %d" % actimeo
                 mtopts += ",actimeo=%d" % actimeo
@@ -216,6 +221,11 @@ class CacheTest(TestUtil):
             if fstat.st_size != dlen:
                 raise Exception("Size of newly created file is %d, should have been %d" %(fstat.st_size, dlen))
 
+            if self.nfsversion >= 4:
+                # revoke delegation
+                self.dprint('DBG3', "revoke delegation")
+                self.clientobj.run_cmd('chmod +x %s' % self.absfile)
+
             if acregmax:
                 # Stat the unchanging file until acregmax is hit
                 # each stat doubles the valid cache time
-- 
2.7.4

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[Su Yanjun <suyj.fnst@cn.fujitsu.com>]

Any ping?

On 2019/1/24 10:30, Su Yanjun wrote:
> When we run nfstest_cache with nfsversion=4, it fails.
> As i know nfsv4 introduces delegation, so nfstest_cache runs fail since nfsv4.
>
> The test commandline is as below:
>   ./nfstest_cache --nfsversion=4 -e  /nfsroot --server 192.168.102.143 --client 192.168.102.142 --runtest acregmax_data --verbose all
>
> This patch adds compatible code for nfsv3 and nfsv4.
> When we test nfsv4, just use 'chmod' to recall delegation, then
> run the test. As 'chmod' will modify atime, so use 'noatime' mount option.
>
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
>   test/nfstest_cache | 12 +++++++++++-
>   1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/test/nfstest_cache b/test/nfstest_cache
> index 0838418..a31d48f 100755
> --- a/test/nfstest_cache
> +++ b/test/nfstest_cache
> @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
>               fd = None
>               attr = 'data' if data_cache else 'attribute'
>               header = "Verify consistency of %s caching with %s on a file" % (attr, self.nfsstr())
> +
>               # Mount options
> -            mtopts = "hard,intr,rsize=4096,wsize=4096"
> +            if self.nfsversion >= 4:
> +                mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> +            else:
> +                mtopts = "hard,intr,rsize=4096,wsize=4096"
> +
>               if actimeo:
>                   header += " actimeo = %d" % actimeo
>                   mtopts += ",actimeo=%d" % actimeo
> @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
>               if fstat.st_size != dlen:
>                   raise Exception("Size of newly created file is %d, should have been %d" %(fstat.st_size, dlen))
>   
> +            if self.nfsversion >= 4:
> +                # revoke delegation
> +                self.dprint('DBG3', "revoke delegation")
> +                self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> +
>               if acregmax:
>                   # Stat the unchanging file until acregmax is hit
>                   # each stat doubles the valid cache time

[PATCH] CACHE: Fix test script as delegation being introduced

[Su Yanjun <suyj.fnst@cn.fujitsu.com>]

When we run nfstest_cache with nfsversion=4, it fails.
As i know nfsv4 introduces delegation, so nfstest_cache runs fail since 
nfsv4.

The test commandline is as below:
./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143 
--client 192.168.102.142 --runtest acregmax_data --verbose all

This patch adds compatible code for nfsv3 and nfsv4.
When we test nfsv4, just use 'chmod' to recall delegation, then
run the test. As 'chmod' will modify atime, so use 'noatime' mount option.

Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
---
test/nfstest_cache | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/test/nfstest_cache b/test/nfstest_cache
index 0838418..a31d48f 100755
--- a/test/nfstest_cache
+++ b/test/nfstest_cache
@@ -165,8 +165,13 @@ class CacheTest(TestUtil):
fd = None
attr = 'data' if data_cache else 'attribute'
header = "Verify consistency of %s caching with %s on a file" % (attr, 
self.nfsstr())
+
# Mount options
- mtopts = "hard,intr,rsize=4096,wsize=4096"
+ if self.nfsversion >= 4:
+ mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
+ else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
+
if actimeo:
header += " actimeo = %d" % actimeo
mtopts += ",actimeo=%d" % actimeo
@@ -216,6 +221,11 @@ class CacheTest(TestUtil):
if fstat.st_size != dlen:
raise Exception("Size of newly created file is %d, should have been %d" 
%(fstat.st_size, dlen))
+ if self.nfsversion >= 4:
+ # revoke delegation
+ self.dprint('DBG3', "revoke delegation")
+ self.clientobj.run_cmd('chmod +x %s' % self.absfile)
+
if acregmax:
# Stat the unchanging file until acregmax is hit
# each stat doubles the valid cache time

-- 
2.7.4

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[J. Bruce Fields]

On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun <suyj.fnst@cn.fujitsu.com> wrote:
> When we run nfstest_cache with nfsversion=4, it fails.
> As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> since nfsv4.
> 
> The test commandline is as below:
> ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> --client 192.168.102.142 --runtest acregmax_data --verbose all
> 
> This patch adds compatible code for nfsv3 and nfsv4.
> When we test nfsv4, just use 'chmod' to recall delegation, then
> run the test. As 'chmod' will modify atime, so use 'noatime' mount option.

I don't think a chmod is a reliable way to recall delegations.

Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:

	Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
	any address  which will  signal to the NFS server that this NFS
	client does not want delegations.

(I wonder if that documentation's still accurate for versions >= 4.1?)

--b.

> 
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
> test/nfstest_cache | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/test/nfstest_cache b/test/nfstest_cache
> index 0838418..a31d48f 100755
> --- a/test/nfstest_cache
> +++ b/test/nfstest_cache
> @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
> fd = None
> attr = 'data' if data_cache else 'attribute'
> header = "Verify consistency of %s caching with %s on a file" %
> (attr, self.nfsstr())
> +
> # Mount options
> - mtopts = "hard,intr,rsize=4096,wsize=4096"
> + if self.nfsversion >= 4:
> + mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> + else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
> +
> if actimeo:
> header += " actimeo = %d" % actimeo
> mtopts += ",actimeo=%d" % actimeo
> @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
> if fstat.st_size != dlen:
> raise Exception("Size of newly created file is %d, should have been
> %d" %(fstat.st_size, dlen))
> + if self.nfsversion >= 4:
> + # revoke delegation
> + self.dprint('DBG3', "revoke delegation")
> + self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> +
> if acregmax:
> # Stat the unchanging file until acregmax is hit
> # each stat doubles the valid cache time
> 
> -- 
> 2.7.4
> 
> 

[Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Su Yanjun]

Hi Frank

We tested the pynfs of NFSv4.0 on the latest version of the kernel 
(5.2.0-rc7).
I encountered a problem while testing st_lock.testOpenUpgradeLock. The 
problem is now as follows:
**************************************************
LOCK24 st_lock.testOpenUpgradeLock : FAILURE
            OP_LOCK should return NFS4_OK, instead got
            NFS4ERR_BAD_SEQID
**************************************************
Is this normal?

The case is as follows:
Def testOpenUpgradeLock(t, env):
     """Try open, lock, open, downgrade, close

     FLAGS: all lock
     CODE: LOCK24
     """
     c= env.c1
     C.init_connection()
     Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
     Os.open(OPEN4_SHARE_ACCESS_READ)
     Os.lock(READ_LT)
     Os.open(OPEN4_SHARE_ACCESS_WRITE)
     Os.unlock()
     Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
     Os.lock(WRITE_LT)
     Os.close()

After investigation, there was an error in unlock->lock. When unlocking, 
the lockowner of the file was not released, causing an error when 
locking again.
Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this function?

Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Su Yanjun]

Ang ping?

在 2019/7/3 9:34, Su Yanjun 写道:
> Hi Frank
>
> We tested the pynfs of NFSv4.0 on the latest version of the kernel 
> (5.2.0-rc7).
> I encountered a problem while testing st_lock.testOpenUpgradeLock. The 
> problem is now as follows:
> **************************************************
> LOCK24 st_lock.testOpenUpgradeLock : FAILURE
>            OP_LOCK should return NFS4_OK, instead got
>            NFS4ERR_BAD_SEQID
> **************************************************
> Is this normal?
>
> The case is as follows:
> Def testOpenUpgradeLock(t, env):
>     """Try open, lock, open, downgrade, close
>
>     FLAGS: all lock
>     CODE: LOCK24
>     """
>     c= env.c1
>     C.init_connection()
>     Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
>     Os.open(OPEN4_SHARE_ACCESS_READ)
>     Os.lock(READ_LT)
>     Os.open(OPEN4_SHARE_ACCESS_WRITE)
>     Os.unlock()
>     Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
>     Os.lock(WRITE_LT)
>     Os.close()
>
> After investigation, there was an error in unlock->lock. When 
> unlocking, the lockowner of the file was not released, causing an 
> error when locking again.
> Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this 
> function?
>
>
>

Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Daniel Gryniewicz]

Is this running knfsd or Ganesha as the server?  If it's Ganesha, the 
question would be better asked on the Ganesha Devel list 
devel@lists.nfs-ganesha.org

If it's knfsd, than Frank isn't the right person to ask.

Daniel

On 7/7/19 10:20 PM, Su Yanjun wrote:
> Ang ping?
> 
> 在 2019/7/3 9:34, Su Yanjun 写道:
>> Hi Frank
>>
>> We tested the pynfs of NFSv4.0 on the latest version of the kernel 
>> (5.2.0-rc7).
>> I encountered a problem while testing st_lock.testOpenUpgradeLock. The 
>> problem is now as follows:
>> **************************************************
>> LOCK24 st_lock.testOpenUpgradeLock : FAILURE
>>            OP_LOCK should return NFS4_OK, instead got
>>            NFS4ERR_BAD_SEQID
>> **************************************************
>> Is this normal?
>>
>> The case is as follows:
>> Def testOpenUpgradeLock(t, env):
>>     """Try open, lock, open, downgrade, close
>>
>>     FLAGS: all lock
>>     CODE: LOCK24
>>     """
>>     c= env.c1
>>     C.init_connection()
>>     Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
>>     Os.open(OPEN4_SHARE_ACCESS_READ)
>>     Os.lock(READ_LT)
>>     Os.open(OPEN4_SHARE_ACCESS_WRITE)
>>     Os.unlock()
>>     Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
>>     Os.lock(WRITE_LT)
>>     Os.close()
>>
>> After investigation, there was an error in unlock->lock. When 
>> unlocking, the lockowner of the file was not released, causing an 
>> error when locking again.
>> Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this 
>> function?
>>
>>
>>
> 
> 

RE: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Frank Filz]

Yea, sorry, I totally missed this, but it does look like it's a Kernel nfsd issue.

Frank

> -----Original Message-----
> From: Daniel Gryniewicz [mailto:dang@redhat.com]
> Sent: Monday, July 8, 2019 6:49 AM
> To: Su Yanjun <suyj.fnst@cn.fujitsu.com>; ffilzlnx@mindspring.com
> Cc: linux-nfs@vger.kernel.org
> Subject: Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
> 
> Is this running knfsd or Ganesha as the server?  If it's Ganesha, the question
> would be better asked on the Ganesha Devel list devel@lists.nfs-ganesha.org
> 
> If it's knfsd, than Frank isn't the right person to ask.
> 
> Daniel
> 
> On 7/7/19 10:20 PM, Su Yanjun wrote:
> > Ang ping?
> >
> > 在 2019/7/3 9:34, Su Yanjun 写道:
> >> Hi Frank
> >>
> >> We tested the pynfs of NFSv4.0 on the latest version of the kernel
> >> (5.2.0-rc7).
> >> I encountered a problem while testing st_lock.testOpenUpgradeLock.
> >> The problem is now as follows:
> >> **************************************************
> >> LOCK24 st_lock.testOpenUpgradeLock : FAILURE
> >>            OP_LOCK should return NFS4_OK, instead got
> >>            NFS4ERR_BAD_SEQID
> >> **************************************************
> >> Is this normal?
> >>
> >> The case is as follows:
> >> Def testOpenUpgradeLock(t, env):
> >>     """Try open, lock, open, downgrade, close
> >>
> >>     FLAGS: all lock
> >>     CODE: LOCK24
> >>     """
> >>     c= env.c1
> >>     C.init_connection()
> >>     Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
> >>     Os.open(OPEN4_SHARE_ACCESS_READ)
> >>     Os.lock(READ_LT)
> >>     Os.open(OPEN4_SHARE_ACCESS_WRITE)
> >>     Os.unlock()
> >>     Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
> >>     Os.lock(WRITE_LT)
> >>     Os.close()
> >>
> >> After investigation, there was an error in unlock->lock. When
> >> unlocking, the lockowner of the file was not released, causing an
> >> error when locking again.
> >> Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this
> >> function?
> >>
> >>
> >>
> >
> >

Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Su Yanjun]

Hi Bruce

在 2019/7/8 22:45, Frank Filz 写道:
> Yea, sorry, I totally missed this, but it does look like it's a Kernel nfsd
Any suggestions?
> issue.
>
> Frank
>
>> -----Original Message-----
>> From: Daniel Gryniewicz [mailto:dang@redhat.com]
>> Sent: Monday, July 8, 2019 6:49 AM
>> To: Su Yanjun <suyj.fnst@cn.fujitsu.com>; ffilzlnx@mindspring.com
>> Cc: linux-nfs@vger.kernel.org
>> Subject: Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in
>> 5.2.0-rc7
>>
>> Is this running knfsd or Ganesha as the server?  If it's Ganesha, the
>> question
>> would be better asked on the Ganesha Devel list
>> devel@lists.nfs-ganesha.org
>>
>> If it's knfsd, than Frank isn't the right person to ask.
We are using the knfsd.
>>
>> Daniel
>>
>> On 7/7/19 10:20 PM, Su Yanjun wrote:
>>> Ang ping?
>>>
>>> 在 2019/7/3 9:34, Su Yanjun 写道:
>>>> Hi Frank
>>>>
>>>> We tested the pynfs of NFSv4.0 on the latest version of the kernel
>>>> (5.2.0-rc7).
>>>> I encountered a problem while testing st_lock.testOpenUpgradeLock.
>>>> The problem is now as follows:
>>>> **************************************************
>>>> LOCK24 st_lock.testOpenUpgradeLock : FAILURE
>>>>             OP_LOCK should return NFS4_OK, instead got
>>>>             NFS4ERR_BAD_SEQID
>>>> **************************************************
>>>> Is this normal?
>>>>
>>>> The case is as follows:
>>>> Def testOpenUpgradeLock(t, env):
>>>>      """Try open, lock, open, downgrade, close
>>>>
>>>>      FLAGS: all lock
>>>>      CODE: LOCK24
>>>>      """
>>>>      c= env.c1
>>>>      C.init_connection()
>>>>      Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
>>>>      Os.open(OPEN4_SHARE_ACCESS_READ)
>>>>      Os.lock(READ_LT)
>>>>      Os.open(OPEN4_SHARE_ACCESS_WRITE)
>>>>      Os.unlock()
>>>>      Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
>>>>      Os.lock(WRITE_LT)
>>>>      Os.close()
>>>>
>>>> After investigation, there was an error in unlock->lock. When
>>>> unlocking, the lockowner of the file was not released, causing an
>>>> error when locking again.
>>>> Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this
>>>> function?
>>>>
>>>>
>>>>
>>>
>
>

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[Su Yanjun]

Hi bruce.

Sorry for my late reply. Our mail system has some problem that ignores your reply.

I Get the reply by google seach.

We tested the option "clientaddr=0.0.0.0" and the test case also fails.

Thanks

On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun<suyj.fnst@cn.fujitsu.com>  wrote:
> When we run nfstest_cache with nfsversion=4, it fails.
> As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> since nfsv4.
> 
> The test commandline is as below:
> ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> --client 192.168.102.142 --runtest acregmax_data --verbose all
> 
> This patch adds compatible code for nfsv3 and nfsv4.
> When we test nfsv4, just use 'chmod' to recall delegation, then
> run the test. As 'chmod' will modify atime, so use 'noatime' mount option.

I don't think a chmod is a reliable way to recall delegations.

Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:

	Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
	any address  which will  signal to the NFS server that this NFS
	client does not want delegations.

(I wonder if that documentation's still accurate for versions >= 4.1?)

--b.
> 
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
> test/nfstest_cache | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/test/nfstest_cache b/test/nfstest_cache
> index 0838418..a31d48f 100755
> --- a/test/nfstest_cache
> +++ b/test/nfstest_cache
> @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
> fd = None
> attr = 'data' if data_cache else 'attribute'
> header = "Verify consistency of %s caching with %s on a file" %
> (attr, self.nfsstr())
> +
> # Mount options
> - mtopts = "hard,intr,rsize=4096,wsize=4096"
> + if self.nfsversion >= 4:
> + mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> + else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
> +
> if actimeo:
> header += " actimeo = %d" % actimeo
> mtopts += ",actimeo=%d" % actimeo
> @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
> if fstat.st_size != dlen:
> raise Exception("Size of newly created file is %d, should have been
> %d" %(fstat.st_size, dlen))
> + if self.nfsversion >= 4:
> + # revoke delegation
> + self.dprint('DBG3', "revoke delegation")
> + self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> +
> if acregmax:
> # Stat the unchanging file until acregmax is hit
> # each stat doubles the valid cache time
> 
> -- 
> 2.7.4
> 
>

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[Olga Kornievskaia]

Hi Su,

For nfstest patches, you should cc nfstest maintainer (Jorge Mora
mora@netapp.com).

On Sun, Jul 28, 2019 at 9:56 PM Su Yanjun <suyj.fnst@cn.fujitsu.com> wrote:
>
> Hi bruce.
>
> Sorry for my late reply. Our mail system has some problem that ignores your reply.
>
> I Get the reply by google seach.
>
> We tested the option "clientaddr=0.0.0.0" and the test case also fails.
>
> Thanks
>
> On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun<suyj.fnst@cn.fujitsu.com>  wrote:
> > When we run nfstest_cache with nfsversion=4, it fails.
> > As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> > since nfsv4.
> >
> > The test commandline is as below:
> > ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> > --client 192.168.102.142 --runtest acregmax_data --verbose all
> >
> > This patch adds compatible code for nfsv3 and nfsv4.
> > When we test nfsv4, just use 'chmod' to recall delegation, then
> > run the test. As 'chmod' will modify atime, so use 'noatime' mount option.
>
> I don't think a chmod is a reliable way to recall delegations.
>
> Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:
>
>         Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
>         any address  which will  signal to the NFS server that this NFS
>         client does not want delegations.
>
> (I wonder if that documentation's still accurate for versions >= 4.1?)
>
> --b.
> >
> > Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> > ---
> > test/nfstest_cache | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/test/nfstest_cache b/test/nfstest_cache
> > index 0838418..a31d48f 100755
> > --- a/test/nfstest_cache
> > +++ b/test/nfstest_cache
> > @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
> > fd = None
> > attr = 'data' if data_cache else 'attribute'
> > header = "Verify consistency of %s caching with %s on a file" %
> > (attr, self.nfsstr())
> > +
> > # Mount options
> > - mtopts = "hard,intr,rsize=4096,wsize=4096"
> > + if self.nfsversion >= 4:
> > + mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> > + else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
> > +
> > if actimeo:
> > header += " actimeo = %d" % actimeo
> > mtopts += ",actimeo=%d" % actimeo
> > @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
> > if fstat.st_size != dlen:
> > raise Exception("Size of newly created file is %d, should have been
> > %d" %(fstat.st_size, dlen))
> > + if self.nfsversion >= 4:
> > + # revoke delegation
> > + self.dprint('DBG3', "revoke delegation")
> > + self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> > +
> > if acregmax:
> > # Stat the unchanging file until acregmax is hit
> > # each stat doubles the valid cache time
> >
> > --
> > 2.7.4
> >
> >
>
>
>

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[bfields]

On Thu, Jan 09, 2020 at 01:54:51AM +0000, Su, Yanjun wrote:
> Any ping about the 1 year old problem?
> Cc mora:
> Did you test nfs cache with nfs version 4?
> Or maybe the test case is not suitable for v4?

I don't run it personally.  Jorge, is it expected to fail in the
presence of delegations?

> Sorry for my late reply. Our mail system has some problem that ignores your reply.
> 
> I Get the reply by google seach.
> 
> We tested the option "clientaddr=0.0.0.0" and the test case also fails.
> 
> Thanks
> 
> On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun<suyj.fnst@cn.fujitsu.com>  wrote:
> 
> When we run nfstest_cache with nfsversion=4, it fails.
> As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> since nfsv4.
> 
> The test commandline is as below:
> ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> --client 192.168.102.142 --runtest acregmax_data --verbose all
> 
> This patch adds compatible code for nfsv3 and nfsv4.
> When we test nfsv4, just use 'chmod' to recall delegation, then
> run the test. As 'chmod' will modify atime, so use 'noatime' mount option.
> 
> I don't think a chmod is a reliable way to recall delegations.

If you run the chmod from the same client, it won't necessarily revoke
the delegation.

If you run it from another client or run it directly on the server, it
should.

> Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:
> 
>     Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
>     any address  which will  signal to the NFS server that this NFS
>     client does not want delegations.
> 
> (I wonder if that documentation's still accurate for versions >= 4.1?)

Probably not.  I don't think there's a way to turn off delegations from
the linux client.

The server may have a way to turn off delegations.  E.g. on a linux
server "echo 0>/proc/sys/fs/leases-enable" before starting knfsd should
do it.

--b.