Bug 1419429 - [Doc] : mdcache on Ganesha needs to be documented
Summary: [Doc] : mdcache on Ganesha needs to be documented
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: doc-Administration_Guide
Version: rhgs-3.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: storage-doc
QA Contact: Prasanth
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 06:43 UTC by Ambarish
Modified: 2022-01-25 16:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-25 16:26:05 UTC
Embargoed:


Attachments (Terms of Use)

Description Ambarish 2017-02-06 06:43:04 UTC
Describe the issue: 
--------------------

Enabling mdcaching on a Ganesha setup needs to be documented separately :

1. Set Attr_Expiration_Time=600 inside exports/<volname>.conf 

2. Run refresh config for changes to be reflected.

This is to be done in addition to setting the mdcache tunables :

  gluster volume set <volname> features.cache-invalidation on
  gluster volume set <volname> features.cache-invalidation-timeout 600
  gluster volume set <volname> performance.stat-prefetch on
  gluster volume set <volname> performance.cache-samba-metadata on     
  gluster volume set <volname> performance.cache-invalidation on
  gluster volume set <volname> performance.md-cache-timeout 600


Suggestions for improvement: 
----------------------------

Include above steps to mdcache documentation as a footnote or something.

Comment 2 rjoseph 2017-02-17 10:14:16 UTC
I assume this attribute belongs to Ganesha Attr_Expiration_Time=600. First of all I don't recommend enabling md-cache in Ganesha because Ganesha maintains its own cache. Secondly is there a need for Attr_Expiration_Time to be in sync with md-cache-timeout? or it just a coincidence that these values are same?

Comment 3 Soumya Koduri 2017-02-20 08:37:44 UTC
(In reply to rjoseph from comment #2)
> I assume this attribute belongs to Ganesha Attr_Expiration_Time=600. First
> of all I don't recommend enabling md-cache in Ganesha because Ganesha
> maintains its own cache. Secondly is there a need for Attr_Expiration_Time
> to be in sync with md-cache-timeout? or it just a coincidence that these
> values are same?

Hi Rajesh,

Yes. That option value is for nfs-ganesha process and by default the value is 60sec. We have been told that there are no protocol specific recommendations done for md-cache settings unless any issues are found wrt functionality or performance. That would mean, admin/customer could try these options even on nfs-ganesha cluster setup. In order to make maximum use of caching (if enabled), we recommend to increase the cache-timeout value in ganesha layer as well to 600sec to match with md-cache timeout value.

Comment 4 rjoseph 2017-02-22 08:45:28 UTC
> Yes. That option value is for nfs-ganesha process and by default the value
> is 60sec. We have been told that there are no protocol specific
> recommendations done for md-cache settings unless any issues are found wrt
> functionality or performance. That would mean, admin/customer could try
> these options even on nfs-ganesha cluster setup. In order to make maximum
> use of caching (if enabled), we recommend to increase the cache-timeout
> value in ganesha layer as well to 600sec to match with md-cache timeout
> value.

Yes, I know for testing md-cache it was told that every module and protocol should test it by enabling it. But practically speaking having two sets of cache on the same side will not benefit the user. In fact the memory consumption will go high without much gain. In your testing have seen any gain in any workload by enabling both ganesha and gluster md-cache? If not then isn't it prudent to recommend only one set of cache for Ganesha?

If your team decides to go ahead with both types of cache then is it OK to add just the Ganesha specific option in a note instead of creating an entirely new section?


Note You need to log in before you can comment on or make changes to this bug.