Question: When NFS client check dir's permission, it does not check the cache data

Hello, everyone
When I test NFS client, I found a poblem that, if a dir we do not have
permission to write, it will let the server to check permissions when we perform the write op.
This is comment by source code:
* Optimize away all write operations, since the server
* will check permissions when we perform the op.
In my test, the process is like following:
#touch dir/file
NFS Server NFS Client

                       <----------      lookup (dir)
lookup ok      ------------->
                       <----------      access (dir)   (*1)
access(read only)   -----------> 
                       <----------      lookup (file)
lookup(NOENT)     ------------->
                       <----------      create (file)  (*2)

create(NOPERM) ------------->

(*1)
First to check the permissions of that dir ,and will be add to cache data. (*2)
Since the Client had known the permission of the dir, why no used it? Does this effect to NFS client's performance?

Quoted 18 lines

Hello, everyone
When I test NFS client, I found a poblem that, if a dir we do not have
permission to write, it will let the server to check permissions when we perform the write op.
This is comment by source code:
* Optimize away all write operations, since the server
* will check permissions when we perform the op.
In my test, the process is like following:
#touch dir/file
NFS Server NFS Client

                       <----------      lookup (dir)
lookup ok      ------------->
                       <----------      access (dir)   (*1)
access(read only)   -----------> 
                       <----------      lookup (file)
lookup(NOENT)     ------------->
                       <----------      create (file)  (*2)

Quoted 8 lines

create(NOPERM) ------------->

(*1)
First to check the permissions of that dir ,and will be add to cache data. (*2)
Since the Client had known the permission of the dir, why no used it? Does this effect to NFS client's performance?

You could, but we don't really have good semantics for how to cache directory information. For files you have close-to-open caching, but for directories, there is no equivalent. I'd therefore prefer to be conservative in cases like this, rather than relying on cached information.

The other question I have is why this is really something worth optimising for? Are there really applications out there with a workload that involves lots of attempts to create files in read-only directories?

Trond

I think code "status = nfs_access_get_cached(inode, cred, &cache);" can do this. And it works.
Other question: why only optimize all write operations, read operations are not optimized? If read options is optimized, it can do the same things, do not use access to check permissions, and server will check permissions when we perform the read op.

Quoted 8 lines

I think code "status = nfs_access_get_cached(inode, cred, &cache);" can do this. And it works.
Other question: why only optimize all write operations, read operations are not optimized? If read options is optimized, it can do the same things, do not use access to check permissions, and server will check permissions when we perform the read op.

Huh? What read operations are we failing to optimise and how?

Quoted 11 lines

Quoted 8 lines

I think code "status = nfs_access_get_cached(inode, cred, &cache);" can do this. And it works.
Other question: why only optimize all write operations, read operations are not optimized? If read options is optimized, it can do the same things, do not use access to check permissions, and server will check permissions when we perform the read op.

Huh? What read operations are we failing to optimise and how?

I mean that read a dir, such as lookup a dir.
If I reply a getattr as that dir has no lookup permission, and then do a "cat /nfsroot/dir/file" at client, client will not send lookup procedure to server, because client used the cache data of the dir. It like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
(send nothing, used cache data)
-------no package is send-------

If no cache data exists, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) ------------------->
<------------- access reply(dir)
(has no lookup permission)

And if has permission to lookup dir, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) -------------------> (*1)
<------------- access reply(dir)
lookup(file) ------------------->
<------------- lookup reply(file)
read(file) ------------------->
<------------- read reply(file)

While you optimize all write operations to omit access procedure, can this access (*1) be omitted? Then lookup(file) will return NOPERM.

Quoted 39 lines

I mean that read a dir, such as lookup a dir.
If I reply a getattr as that dir has no lookup permission, and then do a "cat /nfsroot/dir/file" at client, client will not send lookup procedure to server, because client used the cache data of the dir. It like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
(send nothing, used cache data)
-------no package is send-------

If no cache data exists, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) ------------------->
<------------- access reply(dir)
(has no lookup permission)

And if has permission to lookup dir, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) -------------------> (*1)
<------------- access reply(dir)
lookup(file) ------------------->
<------------- lookup reply(file)
read(file) ------------------->
<------------- read reply(file)

Quoted 3 lines

While you optimize all write operations to omit access procedure, can this access (*1) be omitted? Then lookup(file) will return NOPERM.

So what if I change the permissions on the directory? What should the rules be for caching these attributes?

...and you still haven't replied to my question about what application/workload actually _cares_ about optimising for this particular case.

Quoted 42 lines

Quoted 38 lines

I mean that read a dir, such as lookup a dir.
If I reply a getattr as that dir has no lookup permission, and then do a "cat /nfsroot/dir/file" at client, client will not send lookup procedure to server, because client used the cache data of the dir. It like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
(send nothing, used cache data)
-------no package is send-------

If no cache data exists, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) ------------------->
<------------- access reply(dir)
(has no lookup permission)

And if has permission to lookup dir, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) -------------------> (*1)
<------------- access reply(dir)
lookup(file) ------------------->
<------------- lookup reply(file)
read(file) ------------------->
<------------- read reply(file)

Quoted 4 lines

While you optimize all write operations to omit access procedure, can this access (*1) be omitted? Then lookup(file) will return NOPERM.

Quoted 8 lines

So what if I change the permissions on the directory? What should the rules be for caching these attributes?

...and you still haven't replied to my question about what application/workload actually _cares_ about optimising for this particular case.

No application cares this ^_^, just for test.
I test the read op of dir, it maybe has tiny bug in it. As you said, if I chmod of dir, client will be a little later to know this. Test step ad following:

[root@REHL ~]# mount -t nfs 192.168.0.19:/nfsroot /mnt [root@REHL ~]# ll /mnt
total 4
dr-xr-xr-x 2 root root 4096 Jun 23 2007 dir
[root@REHL ~]# ll /mnt/dir
total 4
-rw-r--r-- 1 root root 5 Jun 24 2007 file
[root@REHL ~]# su weiyj
[weiyj@REHL root]$ ll /mnt
total 4
dr-xr-xr-x 2 root root 4096 Jun 23 2007 dir [weiyj@REHL root]$ ll /mnt/dir
total 4
-rw-r--r-- 1 root root 5 Jun 24 2007 file
[weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ ssh 192.168.0.19 -l root chmod a-x /nfsroot/dir [weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ ll /mnt/dir
total 0
?--------- ? ? ? ? ? /mnt/dir/file
[weiyj@REHL root]$ ll /mnt
total 4
dr--r--r-- 2 root root 4096 Jun 23 2007 dir [weiyj@REHL root]$ cat /mnt/dir/file
cat: /mnt/dir/file: Permission denied

Sorry to trouble again, it is this a real problem of NFS?

Quoted 77 lines

Quoted 42 lines

Quoted 38 lines

I mean that read a dir, such as lookup a dir.
If I reply a getattr as that dir has no lookup permission, and then do a "cat /nfsroot/dir/file" at client, client will not send lookup procedure to server, because client used the cache data of the dir. It like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
(send nothing, used cache data)
-------no package is send-------

If no cache data exists, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) ------------------->
<------------- access reply(dir)
(has no lookup permission)

And if has permission to lookup dir, it would like this:
client server
#ls /nfsroot
readdirplus ------------------>
<------------- readdirplus reply
(attribute of dir has no lookup permission)

# cat /nfsroot/dir/file
access(dir) -------------------> (*1)
<------------- access reply(dir)
lookup(file) ------------------->
<------------- lookup reply(file)
read(file) ------------------->
<------------- read reply(file)

Quoted 4 lines

While you optimize all write operations to omit access procedure, can this access (*1) be omitted? Then lookup(file) will return NOPERM.

Quoted 8 lines

So what if I change the permissions on the directory? What should the rules be for caching these attributes?

...and you still haven't replied to my question about what application/workload actually _cares_ about optimising for this particular case.

No application cares this ^_^, just for test.
I test the read op of dir, it maybe has tiny bug in it. As you said, if I chmod of dir, client will be a little later to know this. Test step ad following:

[root@REHL ~]# mount -t nfs 192.168.0.19:/nfsroot /mnt [root@REHL ~]# ll /mnt
total 4
dr-xr-xr-x 2 root root 4096 Jun 23 2007 dir
[root@REHL ~]# ll /mnt/dir
total 4
-rw-r--r-- 1 root root 5 Jun 24 2007 file
[root@REHL ~]# su weiyj
[weiyj@REHL root]$ ll /mnt
total 4
dr-xr-xr-x 2 root root 4096 Jun 23 2007 dir [weiyj@REHL root]$ ll /mnt/dir
total 4
-rw-r--r-- 1 root root 5 Jun 24 2007 file
[weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ ssh 192.168.0.19 -l root chmod a-x /nfsroot/dir [weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ cat /mnt/dir/file
test
[weiyj@REHL root]$ ll /mnt/dir

Quoted 8 lines

total 0
?--------- ? ? ? ? ? /mnt/dir/file
[weiyj@REHL root]$ ll /mnt
total 4
dr--r--r-- 2 root root 4096 Jun 23 2007 dir
[weiyj@REHL root]$ cat /mnt/dir/file
cat: /mnt/dir/file: Permission denied