From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net
Subject: Re: Question: When NFS client check dir's permission, it does not check the cache data
Date: Thu, 28 Jun 2007 11:06:14 +0800 [thread overview]
Message-ID: <468325A6.9060607@cn.fujitsu.com> (raw)
In-Reply-To: <1182954331.5311.14.camel@heimdal.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
>> 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.
>>
>
> 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
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-06-28 3:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-25 8:52 Question: When NFS client check dir's permission, it does not check the cache data Wei Yongjun
2007-06-25 18:09 ` Muntz, Daniel
2007-06-25 20:08 ` Trond Myklebust
2007-06-27 1:24 ` Wei Yongjun
2007-06-27 3:09 ` Trond Myklebust
2007-06-27 5:22 ` Wei Yongjun
2007-06-27 14:25 ` Trond Myklebust
2007-06-28 3:06 ` Wei Yongjun [this message]
2007-07-26 5:12 ` Wei Yongjun
2007-07-26 16:26 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=468325A6.9060607@cn.fujitsu.com \
--to=yjwei@cn.fujitsu.com \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox