Announce Push of V4-rc2
by Frank Filz
Branch next
Tag:V4-rc2
Ganesha V4.0 is in sight!
Merge Highlights
* NLM - fix issues with SM_NOTIFY handling
* NLM - allow NLM to send messages to IPv4 only clients
* NLM - additional and cleaned up debugging
* PROXY_V4 - fix wrong type used for return value
* KVSFS - cleanup supported bits
* CEPH - fix stuck readdir
* Always initialize rwlock when creating acl object
* Do not read a fsal_filesystem if type is incomplete
* Fix flood of "fsal_common_is_referral :FSAL :EVENT :Failed to get attrs
for referral" messages.
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
ef07e96e2 Frank S. Filz V4-rc2
4f2bf3953 Nuzhat Fathima Shaik Fix flood of "fsal_common_is_referral :FSAL
:EVENT :Failed to get attrs for referral" messages.
7e5502b09 Matthew DeVore Do not read a fsal_filesystem if type is incomplete
b5b55dc39 Matthew DeVore Always initialize rwlock when creating acl object
a5cc08308 fenghua Zhen Fix readdir stuck. When ceph-radosgw returns part of
the dirs results, ganesha marks the last result as DIR_TERMINATE and rescan,
caused an endless loop.
0eab09fa0 Frank S. Filz Cleanup some bits of what is supported in FSAL_KVSFS
a5c0e66a9 Frank S. Filz PROXY_V4: proxyv4_rpc_read_reply returns an int,
don't store in an enum
c58c033cf Frank S. Filz NLM: for async response, if no IPv6 address is
available convert IPv4 address
08c11eff7 Frank S. Filz Fix up SM_NOTIFY caller_name
5df7769e7 Frank S. Filz NLM: Use IPv4 address instead of encapsulated for
caller_name
dc03cb3dc Frank S. Filz Remove nlm_owner reference count held by nlm_state
38b5e8dd6 Frank S. Filz nsm client always has a caller_name, don't use
ssc_client in hash
aa5e540d4 Frank S. Filz Improve nsm_client debugging
f7711bbc7 Frank S. Filz Fixup a wrong log component, nlm_util should be
COMPONENT_NLM
8b38e8b96 Frank S. Filz Remove unused parameter from get_nsm_client
eb283dee7 Frank S. Filz Move convert_ipv6_to_ipv4 to rpc_tools.c and add
is_loopback
2 years, 5 months
New to NFS Ganesha - seeking general info on tuning and benchmarking
by zlaymonk＠gmail.com
Hi,
We have a 2-node NFS ganesha cluster (using CTDB), that I recently inherited administration for.
Most of our internal users are satisfied with the performance, but one particular user has had all sorts of performance related issues affecting their adoption and usage of the NFS shares. From initial analysis, this seems to be a problem of loading (because it occurs during intensive reads/writes of large datasets, such as during rsync transfers or backup reads).
So far, I have not yet been able to establish whether the problem is due to the number of files or the volume of data, and I am now setting up test client nodes to try and reproduce the client's issues.
I googled around seeking information on tuning (kernel, NFS, OS, etc), but cannot seem to find any at all. Please, can someone share some insight into how to go about trying to optimize the performance of ganesha. Also, would appreciate any insight /suggestion on how best to benchmark the performance.
Thanks in advance
2 years, 6 months
