On 09/30/2016 08:46 AM, Tushar Shinde wrote: > On Thu, Sep 29, 2016 at 9:12 PM, Frank Filz <ffilz...@mindspring.com> wrote: >>> On Wed, Sep 28, 2016 at 10:03 PM, Frank Filz <ffilz...@mindspring.com> >>> wrote: >>>> The same lock owner never has conflicts so one file descriptor per owner >>> per file with OFD locks satisfies all the needs. >>>> >>>> We are planning on separating out the code in SAL that manages the union >>> of all locks. FSALs that have no other way to support lock owners will have >>> to >>> replicate the lock list inside the FSAL and utilize some code to manage the >>> union of all locks. We may provide an untested helper function in >>> FSAL/commonlib.c. >>>> What is your environment? It sounds like you will be using FSAL_VFS in >>> some way, but don't have OFD locks. Are you using an older Linux or >>> FreeBSD? >>>> >>> I am using vxfs on RHEL-6.7. >> >> Curious why you want to run without MDCACHE. > > The upcall cache invalidation framework not in place for this FSAL. > I am interested in knowing performance difference when caching is done > at user level and when it happens only at FS/kernel level. VXFS is > cluster file system, Its important to evaluate how much user mode > cache is contributing to our workloads vs cost of invalidation > framework. With 2.4 separate mdcache plug able layer this may be > easily possible. > Is there any plan to harden NO-MDCACHE code paths moving forward? For > now I will try code with mdcache. >
Yes. The plan is to convert FSAL_RGW at least, and possibly FSAL_CEPH into cacheless. However, those efforts are currently prioritized below general performance improvements in Ganesha, which is the focus of at least the early portions of 2.5 for me. Daniel ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
