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>>