8:57 a.m.
-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(a)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(a)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(a)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(a)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(a)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(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>>
<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(a)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(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>>
<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>>>