Re: [PATCH 09/17] NFSv4: Introduce new label structure

[Steve Dickson <SteveD-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 08/05/13 14:56, J. Bruce Fields wrote:
> On Wed, May 08, 2013 at 06:06:24PM +0000, Myklebust, Trond wrote:
>> On Wed, 2013-05-08 at 13:32 -0400, Steve Dickson wrote:
>>> Not the label but the inode. The bit is set in ACCESS, LOOKUP, 
>>> LINK, OPEN, CREAT, SETATTR which all clearly update the inode.
>>>
>>> So I guess my question is if the bit is not set in any of these 
>>> ops how do we know if the label has changed? Should label changes
>>> be synchronized with inode updates? 
>>
>> I know that Bruce doesn't like FATTR4_CHANGE_SEC_LABEL,
> 
> Not true at all, sorry to give that impression.
> 
> It doesn't look like a lot of work to implement (how much work would it
> be to use on the client side?), and I'd be perfectly happy if someone
> would do so.
> 
> It's just that noone's volunteered, and my todo list is out of control
> as it is.
> 
>> but that is the
>> only option I can see for implementing a cache consistency model for
>> labels. Without it, the choices are:
>>
>> 1) always fetch the label as part of every COMPOUND.
>> 2) assume the label never changes on the server.
>>
>> The main use cases that have been presented for Labeled NFS on Linux
>> would tend to push me towards door number 2, Monty please...
> 
> And that's fine with me too.

This being the case... Are you saying setting the label only needs
to be set during the nfs_fhget(), _nfs4_do_open() and nfs4_set_security_label().

Which means the setting of the label will be removed from nfs_refresh_inode()
and all its callers.... correct?

steved.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html