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@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@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@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>
Few more observation Denial, 1) in our stack trace we are seeing mdcache_setattrs not setattr2. 2) in mdcache_refresh_attr, cache will be invalidated only for directory. 3) in mdcache_setattrs ACL is not requested. Thanks, Sagar. On Thu, Apr 26, 2018 at 1:19 PM, Sagar M D <sagar.md@gmail.com> 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@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@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@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>
Then your FSAL doesn't use support_ex, and so it might not work well. non-support_ex hasn't been tested well in 2.6 (and is gone entirely in 2.7) since all the in-tree FSALs use support_ex. Daniel On 04/26/2018 09:07 AM, Sagar M D wrote:
Few more observation Denial,
1) in our stack trace we are seeing mdcache_setattrs not setattr2. 2) in mdcache_refresh_attr, cache will be invalidated only for directory. 3) in mdcache_setattrs ACL is not requested.
Thanks, Sagar.
On Thu, Apr 26, 2018 at 1:19 PM, Sagar M D <sagar.md@gmail.com <mailto:sagar.md@gmail.com>> 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@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@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@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@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@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@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>>
Daniel, is there any to disable ganesha caching then for now (till we move to support_ex apis)? I see this in config.txt, but what needs to set to disable it ? -1 ? Attr_Expiration_Time(int32, range -1 to INT32_MAX, default 60) * Attr_Expiration_Time is evaluated when an MDCACHE entry is created, so the dynamic effect of this option may be constrained to new entries. Thanks, Sagar. On Thu, Apr 26, 2018 at 6:44 PM, Daniel Gryniewicz <dang@redhat.com> wrote:
Then your FSAL doesn't use support_ex, and so it might not work well. non-support_ex hasn't been tested well in 2.6 (and is gone entirely in 2.7) since all the in-tree FSALs use support_ex.
Daniel
On 04/26/2018 09:07 AM, Sagar M D wrote:
Few more observation Denial,
1) in our stack trace we are seeing mdcache_setattrs not setattr2. 2) in mdcache_refresh_attr, cache will be invalidated only for directory. 3) in mdcache_setattrs ACL is not requested.
Thanks, Sagar.
On Thu, Apr 26, 2018 at 1:19 PM, Sagar M D <sagar.md@gmail.com <mailto: sagar.md@gmail.com>> 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@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@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@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@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@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@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>>
-1 should disable it, but it looks like a few checks compare to 0, so try setting it to 0 to be safe. Daniel On 04/26/2018 09:31 AM, Sagar M D wrote:
Daniel, is there any to disable ganesha caching then for now (till we move to support_ex apis)? I see this in config.txt, but what needs to set to disable it ? -1 ?
Attr_Expiration_Time(int32, range -1 to INT32_MAX, default 60)
* Attr_Expiration_Time is evaluated when an MDCACHE entry is created, so the dynamic effect of this option may be constrained to new entries.
Thanks,
Sagar.
On Thu, Apr 26, 2018 at 6:44 PM, Daniel Gryniewicz <dang@redhat.com <mailto:dang@redhat.com>> wrote:
Then your FSAL doesn't use support_ex, and so it might not work well. non-support_ex hasn't been tested well in 2.6 (and is gone entirely in 2.7) since all the in-tree FSALs use support_ex.
Daniel
On 04/26/2018 09:07 AM, Sagar M D wrote:
Few more observation Denial,
1) in our stack trace we are seeing mdcache_setattrs not setattr2. 2) in mdcache_refresh_attr, cache will be invalidated only for directory. 3) in mdcache_setattrs ACL is not requested.
Thanks, Sagar.
On Thu, Apr 26, 2018 at 1:19 PM, Sagar M D <sagar.md@gmail.com <mailto:sagar.md@gmail.com> <mailto:sagar.md@gmail.com <mailto:sagar.md@gmail.com>>> 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@redhat.com <mailto:dang@redhat.com> <mailto:dang@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@redhat.com <mailto:dang@redhat.com> <mailto:dang@redhat.com <mailto:dang@redhat.com>> <mailto:dang@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@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> <mailto:devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org>> <mailto:devel@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@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>> <mailto:devel-leave@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@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> <mailto:devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org>> <mailto:devel@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@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>> <mailto:devel-leave@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>>>
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@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@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@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@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@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@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>>
participants (2)
-
Daniel Gryniewicz -
Sagar M D