It should.  It should invalidate the attributes on mdc_lookup_dst, which 
is what you wanted.

Daniel

On 10/13/2016 01:29 PM, Frank Filz wrote:
>> I suspect the correct solution is to mark attrs untrusted in
>> mdc_unreachable().
>
> That doesn't help the entry being renamed though, which is actually the 
> biggest concern.
>
> Frank
>
>> On Wed, Oct 12, 2016 at 6:29 PM, Frank Filz <ffilz...@mindspring.com>
>> wrote:
>>> Dan,
>>>
>>> In cache_inode_rename, we did a lookup of both the old name and the
>>> new name, and refreshed attributes on both objects.
>>>
>>> In mdcache, I'm not sure we invalidate the attributes of
>>> mdc_lookup_dst (if any, the object that is unlinked as a result of rename
>> onto it).
>>>
>>> What this results in is that a rename of a file causes us to not
>>> reflect the updated ctime to the client.
>>>
>>> I think we need to do an mdc_try_get_cached on old name, and if that
>>> results in a cached object, to invalidate it's attributes.
>>>
>>> Similarly, if mdc_lookup_dst is non-NULL, we need to invalidate it's
>>> attributes (if it had multiple hard links, a rename over it should
>>> change it's ctime also). If we just evict it from cache, then that works 
>>> also.
>>>
>>> What do you think?
>>>
>>> Anyone else have thoughts?
>>>
>>> Thanks
>>>
>>> Frank
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to