8:31 a.m.
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(a)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(a)gmail.com <mailto:
> sagar.md(a)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(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>>
>
>
>
>
>
>