8:11 a.m.
It's possible, but it shouldn't matter, I think. Here's the sequence of
events:
In mdcache_setattr2():
sub_handle->setattr2() - call into sub-FSAL to actually set the new
attributes.
if (MODE | OWNER | GROUP | ACL)
need_acl = true
mdcache_refresh_attrs(need_acl)
Then, in mdcache_refresh_attrs():
request_mask = export.fs_supported_attrs() - Note this sets ATTR_ACL
if (!need_acl)
clear ATTR_ACL in request_mask
sub_handle->getattrs() - Get the new attributes
mdc_update_attr_cache() - Update our attribute cache with the new attrs
if (mtime_changed)
mdcache_dirent_invalidate_all() - Invalidate the dirent cache
As you can see, if MODE changes, the only conditional bit in this whole
sequence is the dirent invalidation. The attribute cache is
unconditionally updated, including the ACLs.
Daniel
On 04/26/2018 03:49 AM, Sagar M D wrote:
Denial,
I went through "mdcache_refresh_attrs" which is called to invalidate the
cache based on mtime.
change mode wont change the mtime, it changes only ctime alone.
Do you think, ctime also to be considered for invalidating the cache?
On local ext3 filesystem, i see chmod changes only ctime.
[root@ tmp]# stat 1.txt
File: ‘1.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular
empty file
Device: fd00h/64768d Inode: 845864 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2018-04-24 14:45:18.869208038 +0530
Modify: 2018-04-24 14:45:18.869208038 +0530
*Change: 2018-04-24 14:45:18.869208038 +0530*
Birth: -
[root@ tmp]# chmod 777 1.txt
[root@ tmp]# stat 1.txt
File: ‘1.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular
empty file
Device: fd00h/64768d Inode: 845864 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2018-04-24 14:45:18.869208038 +0530
Modify: 2018-04-24 14:45:18.869208038 +0530
*Change: 2018-04-26 12:29:45.446766807 +0530*
Birth: -
Thanks,
Sagar.
On Wed, Apr 25, 2018 at 7:03 PM, Daniel Gryniewicz <dang(a)redhat.com
<mailto:dang@redhat.com>> wrote:
I was assuming you meant the mode changed behind Ganesha's back. If
the only changes are coming through Ganesha, it shouldn't be a
problem, right? In mdcache_setattr2(), it checks to see if ACL,
MODE, OWNER, or GROUP changes, and if so, refreshed the ACLs along
with the other attributes.
Daniel
On 04/25/2018 09:24 AM, Sagar M D wrote:
Hi Daniel,
chmod call also will go through ganesha to fsal. So ganesha
should invalidate the old cache and update itself with new
attribute in the cache right ?
On what basis ganesha will invalidate the cache, only through up
call from fsal and time based?
Thanks,
Sagar.
On Wed, Apr 25, 2018 at 5:33 PM, Daniel Gryniewicz
<dang(a)redhat.com <mailto:dang@redhat.com>
<mailto:dang@redhat.com <mailto:dang@redhat.com>>> wrote:
Hi, Sagar.
Not just ACLs are cached, mode bits are as well. So the
correct
solution is to send an UP-call when the mode bits change to
invalidate the cache on that object.
Daniel
On 04/25/2018 06:46 AM, Sagar M D wrote:
Hi,
Can we disable ACL cache through some configuration?
We are converting mode bits to ACE in our FSAL. Due to ACL
caching, ganesha is not calling into fsal to get the ACL.
So if there is any mode change after ganesha caches
initial ACL,
Ganesha just sends the old mode bits ACL from the cache
itself.
These are the operation performed.
[root@ ACL_Demo]# touch 20.txt
[root@ ACL_Demo]# nfs4_getfacl 20.txt
A::OWNER@:rwatTnNcC
A::GROUP@:rtnc
A::EVERYONE@:rtnc
[root@ ACL_Demo]# chmod 777 20.txt
[root@ ACL_Demo]# nfs4_getfacl 20.txt
A::OWNER@:rwatTnNcC
A::GROUP@:rtnc
A::EVERYONE@:rtnc
Any help would be appreciated here.
Thanks,
Sagar.
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
<mailto:devel@lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>>
To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
<mailto:devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
<mailto:devel@lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>>
To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
<mailto:devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>>