From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Question: When NFS client check dir's permission,
	it	does not check the cache data
Date: Wed, 27 Jun 2007 10:25:31 -0400
Message-ID: <1182954331.5311.14.camel@heimdal.trondhjem.org>
References: <467F8247.9060607@cn.fujitsu.com>
	<1182802099.6163.33.camel@heimdal.trondhjem.org>
	<4681BC44.6000605@cn.fujitsu.com>
	<1182913754.12836.61.camel@heimdal.trondhjem.org>
	<4681F3FB.7040609@cn.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net
To: Wei Yongjun <yjwei@cn.fujitsu.com>
In-Reply-To: <4681F3FB.7040609@cn.fujitsu.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Wed, 2007-06-27 at 13:22 +0800, Wei Yongjun wrote:
> >
> >> 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.

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.

Trond


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs