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>