Option noac not working correctly?

Option noac not working correctly?

[Diego Moreno]

Hello everyone,

I've been testing the noac mount option in several kernels (2.6.27.10, 
2.6.29-rc8) for NFSv3 and NFSv4. The next commands do not work properly:

rm -f /export/B; ls -l /tmp/nfs_client_tcp/B ; uname -a > /export/B; ls 
-l /tmp/nfs_client_tcp/B

Result is usually:

ls: /tmp/nfs_client_tcp/B: No such file or directory
ls: /tmp/nfs_client_tcp/B: No such file or directory

Actually the result should be always:

ls: /tmp/nfs_client_tcp/B: No such file or directory
-rw-r--r-- 1 root root 89 Mar 18 14:02 /tmp/nfs_client_tcp/B

Network traces show me that client is not making any lookup in the 
server for the second 'ls'. A client with noac option should always make 
a lookup on server, isn't it?

My /etc/exports file:

/export  *(rw,fsid=0,insecure,no_subtree_check)

Relevant information from cat /proc/mounts:

pwrd:/ /tmp/nfs_client_tcp nfs4 
rw,sync,vers=4,rsize=1048576,wsize=1048576,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,nointr,noac,proto=tcp,timeo=600,retrans=2,sec=sys

NFS debug trace of the second ls command:

NFS call  access
NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
NFS reply access: 0
NFS: permission(0:17/2), mask=0x1, res=0
NFS: revalidating (0:17/2)
NFS call  getattr
NFS reply getattr: 0
NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
NFS: nfs3_forget_cached_acls(0:17/2)
NFS: (0:17/2) revalidation complete
NFS: nfs_lookup_revalidate(/B) is valid
NFS: dentry_delete(/B, 8)

Is there anything I'm not doing well? Is this a known bug for the last 
kernel version? Thanks,

D. Moreno

Re: Option noac not working correctly?

[Trond Myklebust]

On Wed, 2009-03-18 at 15:36 +0100, Diego Moreno wrote:
> Hello everyone,
> 
> I've been testing the noac mount option in several kernels (2.6.27.10, 
> 2.6.29-rc8) for NFSv3 and NFSv4. The next commands do not work properly:
> 
> rm -f /export/B; ls -l /tmp/nfs_client_tcp/B ; uname -a > /export/B; ls 
> -l /tmp/nfs_client_tcp/B
> 
> Result is usually:
> 
> ls: /tmp/nfs_client_tcp/B: No such file or directory
> ls: /tmp/nfs_client_tcp/B: No such file or directory
> 
> Actually the result should be always:
> 
> ls: /tmp/nfs_client_tcp/B: No such file or directory
> -rw-r--r-- 1 root root 89 Mar 18 14:02 /tmp/nfs_client_tcp/B
> 
> Network traces show me that client is not making any lookup in the 
> server for the second 'ls'. A client with noac option should always make 
> a lookup on server, isn't it?
> 
> My /etc/exports file:
> 
> /export  *(rw,fsid=0,insecure,no_subtree_check)
> 
> Relevant information from cat /proc/mounts:
> 
> pwrd:/ /tmp/nfs_client_tcp nfs4 
> rw,sync,vers=4,rsize=1048576,wsize=1048576,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,nointr,noac,proto=tcp,timeo=600,retrans=2,sec=sys
> 
> NFS debug trace of the second ls command:
> 
> NFS call  access
> NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
> NFS reply access: 0
> NFS: permission(0:17/2), mask=0x1, res=0
> NFS: revalidating (0:17/2)
> NFS call  getattr
> NFS reply getattr: 0
> NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
> NFS: nfs3_forget_cached_acls(0:17/2)
> NFS: (0:17/2) revalidation complete
> NFS: nfs_lookup_revalidate(/B) is valid
> NFS: dentry_delete(/B, 8)
> 
> Is there anything I'm not doing well? Is this a known bug for the last 
> kernel version? Thanks,

The above behaviour is perfectly correct _if_ the mtime
on /tmp/nfs_client_tcp doesn't change between your 'rm' and the creation
of B. Given that most Linux filesystems have poor (1 second) resolution
on mtime, then for it not to change in the above test is an extremely
likely event.

Note that there is a better option for controlling lookup behaviour in
newer kernels: -olookupcache=all or -olookupcache=positive should both
cause your test above to pass irrespective of whether or not mtime
changed.

Trond

Re: Option noac not working correctly?

[Diego Moreno]

Trond Myklebust wrote:
> On Wed, 2009-03-18 at 15:36 +0100, Diego Moreno wrote:
>> Hello everyone,
>>
>> I've been testing the noac mount option in several kernels (2.6.27.10, 
>> 2.6.29-rc8) for NFSv3 and NFSv4. The next commands do not work properly:
>>
>> rm -f /export/B; ls -l /tmp/nfs_client_tcp/B ; uname -a > /export/B; ls 
>> -l /tmp/nfs_client_tcp/B
>>
>> Result is usually:
>>
>> ls: /tmp/nfs_client_tcp/B: No such file or directory
>> ls: /tmp/nfs_client_tcp/B: No such file or directory
>>
>> Actually the result should be always:
>>
>> ls: /tmp/nfs_client_tcp/B: No such file or directory
>> -rw-r--r-- 1 root root 89 Mar 18 14:02 /tmp/nfs_client_tcp/B
>>
>> Network traces show me that client is not making any lookup in the 
>> server for the second 'ls'. A client with noac option should always make 
>> a lookup on server, isn't it?
>>
>> My /etc/exports file:
>>
>> /export  *(rw,fsid=0,insecure,no_subtree_check)
>>
>> Relevant information from cat /proc/mounts:
>>
>> pwrd:/ /tmp/nfs_client_tcp nfs4 
>> rw,sync,vers=4,rsize=1048576,wsize=1048576,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,nointr,noac,proto=tcp,timeo=600,retrans=2,sec=sys
>>
>> NFS debug trace of the second ls command:
>>
>> NFS call  access
>> NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
>> NFS reply access: 0
>> NFS: permission(0:17/2), mask=0x1, res=0
>> NFS: revalidating (0:17/2)
>> NFS call  getattr
>> NFS reply getattr: 0
>> NFS: nfs_update_inode(0:17/2 ct=2 info=0x6)
>> NFS: nfs3_forget_cached_acls(0:17/2)
>> NFS: (0:17/2) revalidation complete
>> NFS: nfs_lookup_revalidate(/B) is valid
>> NFS: dentry_delete(/B, 8)
>>
>> Is there anything I'm not doing well? Is this a known bug for the last 
>> kernel version? Thanks,
> 
> The above behaviour is perfectly correct _if_ the mtime
> on /tmp/nfs_client_tcp doesn't change between your 'rm' and the creation
> of B. Given that most Linux filesystems have poor (1 second) resolution
> on mtime, then for it not to change in the above test is an extremely
> likely event.
> 
> Note that there is a better option for controlling lookup behaviour in
> newer kernels: -olookupcache=all or -olookupcache=positive should both
> cause your test above to pass irrespective of whether or not mtime
> changed.
> 
> Trond

Thanks for your quick reply Trond. I've seen the only way to pass my 
test is using (for kernel 2.6.29-rc8): -olookupcache=positive,noac. If I 
use -olookupcache=positive or -olookupcache=all or 
-olookupcache=all,noac my test doesn't pass.

BTW, is there any way of passing this test for a kernel like 2.6.27 
(there is no lookupcache mount option). In kernels like 2.6.19 or 2.6.20 
I think I passed my test just using noac option. These kernels where the 
first kernels with the patch (commit 
b0b539739fe9b7d75002412a787cfdf4efddbc33) treating the special case of 
nfsi->attrtimeo==0. That means 'noac' or/and actimeo=0 mount options.

Thanks,

Diego

Re: Option noac not working correctly?

[Trond Myklebust]

On Wed, 2009-03-18 at 17:42 +0100, Diego Moreno wrote:
> Thanks for your quick reply Trond. I've seen the only way to pass my 
> test is using (for kernel 2.6.29-rc8): -olookupcache=positive,noac. If I 
> use -olookupcache=positive or -olookupcache=all or 
> -olookupcache=all,noac my test doesn't pass.

Sorry. You're right... The -olookupcache option only affects lookup of
new files (and I should have said "-olookupcache=positive" or
"-olookupcache=none").
In this test case you are, however doing an 'ls', not a lookup. The
resulting opendir() call will always check if the directory has changed
or not on the NFS server (irrespective of whether or not you use
'noac'). The decision on whether or not to rely on the cached readdir
data then depends entirely on whether or not the server returns a new
value for the NFSv4 change_attribute or the mtime.

The problem therefore is, as I indicated earlier, that the server is
telling the client that nothing changed because it has too poor mtime
resolution...

> BTW, is there any way of passing this test for a kernel like 2.6.27 
> (there is no lookupcache mount option). In kernels like 2.6.19 or 2.6.20 
> I think I passed my test just using noac option. These kernels where the 
> first kernels with the patch (commit 
> b0b539739fe9b7d75002412a787cfdf4efddbc33) treating the special case of 
> nfsi->attrtimeo==0. That means 'noac' or/and actimeo=0 mount options.

'noac' cannot fix this problem.

Cheers
  Trond