recent subscribe requests
by Kaleb Keithley
Hi,
Several people recently subscribed to the ganesha devel list. Unfortunately
I fat-fingered one of them and accidentally rejected the request. And I
can't find where to undo the request.
If you recently subscribed you may wish to try again. (And I realize that
you have to be subscribed to the list to see this, so it's a bit of a
Catch-22 here; unless you're reading the archive.)
And in the meantime we've decided to make the lists "open" and subscribe
requests will be accepted without moderator approval.
--
Kaleb
5 months, 1 week
Change in ...nfs-ganesha[next]: EXPORT: Set expire_time_attr for export root.
by Name of user not set (GerritHub)
pradeepthomas(a)gmail.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494233 )
Change subject: EXPORT: Set expire_time_attr for export root.
......................................................................
EXPORT: Set expire_time_attr for export root.
MDCACHE sets expire_time_attr based on either what FSAL returns
or from op_ctx->export_perms. This patch initializes expire_time_attr
in op_ctx->export_perms before calling lookup_path from
init_export_root.
Suggested-by: Frank Filz
Signed-off-by: Pradeep <pradeepthomas(a)gmail.com>
Change-Id: Ie75ea06253bdff67f735d116c301ac39f7bc1a85
---
M src/support/exports.c
1 file changed, 22 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/33/494233/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494233
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Ie75ea06253bdff67f735d116c301ac39f7bc1a85
Gerrit-Change-Number: 494233
Gerrit-PatchSet: 1
Gerrit-Owner: pradeepthomas(a)gmail.com
Gerrit-MessageType: newchange
5 months, 1 week
Change in ...nfs-ganesha[next]: Add NFSv4.1 and NFSv4.2 io stats.
by xijinyu (GerritHub)
xijinyu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494211 )
Change subject: Add NFSv4.1 and NFSv4.2 io stats.
......................................................................
Add NFSv4.1 and NFSv4.2 io stats.
ganesha_stats iov4 <export id> :
It can only record NFSv4.0 io stats,
It can't record NFSv4.1 and nfsv4.2 IO stats.
Signed-off-by: Xi Jinyu <xijinyu(a)cmss.chinamobile.com>
Change-Id: I4264c9f67ccb4383995745913acef43cb6247c2f
---
M src/scripts/ganeshactl/Ganesha/glib_dbus_stats.py
M src/scripts/ganeshactl/ganesha_stats.py
M src/support/client_mgr.c
M src/support/export_mgr.c
4 files changed, 270 insertions(+), 5 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/11/494211/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494211
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I4264c9f67ccb4383995745913acef43cb6247c2f
Gerrit-Change-Number: 494211
Gerrit-PatchSet: 1
Gerrit-Owner: xijinyu <xijinyu(a)cmss.chinamobile.com>
Gerrit-MessageType: newchange
5 months, 1 week
expire_time_attr for root of the export.
by Pradeep Thomas
Hello,
The expire_time_attr is set by mdcache_new_entry() and is copied from either FSAL attrs or
op_ctx->export_perms->expire_time_attr. For root of the export, I see this as zero. I think it
is because the root handle is created through lookup_path() and op_ctx is initialized through
init_root_op_context which doesn't set export_perms.expire_time_attr.
The zero expire_time_attr causes every getattr to go to FSAL. Since getattr is called from
several places, this ends up increasing the path length of the call (for ex: READDIR under
export root).
What is the right fix for this? Initializing in init_root_op_context() OR let FSAL to return a
non-zero value?
#0 mdcache_new_entry (export=export@entry=0x555555766ea0, sub_handle=0x555555764c50,
attrs_in=attrs_in@entry=0x7fffffffdda0, attrs_out=attrs_out@entry=0x0, new_directory=new_directory@entry=false,
entry=entry@entry=0x7fffffffdd98, state=0x0, reason=MDC_REASON_DEFAULT)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:664
#1 0x00007ffff7b1ac76 in mdcache_lookup_path (exp_hdl=0x555555766ea0, path=0x555555767470 "/nfsroot",
handle=0x7fffffffdee8, attrs_out=0x0)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1566
#2 0x00007ffff7aab25c in init_export_root (export=export@entry=0x555555766368)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/support/exports.c:2321
#3 0x00007ffff7aacce5 in init_export_cb (exp=0x555555766368, state=0x7fffffffe0b0)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/support/exports.c:2185
#4 0x00007ffff7ac0b44 in foreach_gsh_export (cb=cb@entry=0x7ffff7aaccd0 <init_export_cb>, wrlock=wrlock@entry=true,
state=state@entry=0x7fffffffe0b0) at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/support/export_mgr.c:784
#5 0x00007ffff7aaaf3a in exports_pkginit () at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/support/exports.c:2204
#6 0x00007ffff7a382f5 in nfs_Init (p_start_info=<optimized out>)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/MainNFSD/nfs_init.c:644
#7 0x00007ffff7a39c1b in nfs_start (p_start_info=<optimized out>)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/MainNFSD/nfs_init.c:925
#8 0x00005555555565a9 in main (argc=<optimized out>, argv=<optimized out>)
at /usr/src/debug/nfs-ganesha-3.2-1.el8.x86_64/src/MainNFSD/nfs_main.c:519
(gdb) p *op_ctx
$1 = {creds = 0x7fffffffdfe8, original_creds = {caller_uid = 0, caller_gid = 0, caller_glen = 0, caller_garray = 0x0},
caller_gdata = 0x0, caller_garray_copy = 0x0, managed_garray_copy = 0x0, cred_flags = 0, caller_addr = 0x0,
clientid = 0x0, nfs_vers = 0, nfs_minorvers = 0, req_type = 0, client = 0x0, ctx_export = 0x555555766368,
fsal_export = 0x555555766ea0, export_perms = 0x7fffffffe000, start_time = 0, fsal_private = 0x0,
fsal_module = 0x7ffff7dc0100 <MDCACHE>, fsal_pnfs_ds = 0x0}
(gdb) p *op_ctx->export_perms
$2 = {anonymous_uid = 0, anonymous_gid = 0, expire_time_attr = 0, options = 124908000, set = 124908031}
5 months, 1 week
Change in ...nfs-ganesha[next]: Stop reaper threads before worker threads when shutting down
by Sriram Patil (GerritHub)
Sriram Patil has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/493905 )
Change subject: Stop reaper threads before worker threads when shutting down
......................................................................
Stop reaper threads before worker threads when shutting down
Worker threads may take time to shutdown because of the inflight
operations. During this time a client state can expire and reaper thread
may delete the client recovery directories before shutdown. This means, the
client will not be able to recover the state after server restart/failover.
Ganesha shutdown sequence is changed to stop reaper threads before worker
threads to avoid unfortunate client state deletion.
Change-Id: Id545950d45fb23869dd1aacda2acf32ca08908c7
Signed-off-by: Sriram Patil <sriramp(a)vmware.com>
---
M src/MainNFSD/nfs_admin_thread.c
1 file changed, 10 insertions(+), 9 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/05/493905/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/493905
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Id545950d45fb23869dd1aacda2acf32ca08908c7
Gerrit-Change-Number: 493905
Gerrit-PatchSet: 1
Gerrit-Owner: Sriram Patil <sriramp(a)vmware.com>
Gerrit-MessageType: newchange
5 months, 1 week
TIRPC efficient work thread scheduling
by gaurav gangalwar
Hi,
https://github.com/nfs-ganesha/ntirpc/pull/213
I added this fix to try to process more requests with less scheduling.
Scheduling overhead causes big impact in case of low latency workloads.
We got more than 80% benefit for 8k random cached reads with the fix. It has
overall positive impact on other workloads also like random write,
sequential read/write with single and multiple clients.
-Gaurav
5 months, 2 weeks
Change in ...nfs-ganesha[next]: bugfix: initialization ea_entry->e_perm before get permission value
by MuYao Luo (GerritHub)
MuYao Luo has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/493749 )
Change subject: bugfix: initialization ea_entry->e_perm before get permission value
......................................................................
bugfix: initialization ea_entry->e_perm before get permission value
ea_entry was alloc by gsh_malloc which not initialized previously, so the
value in entry->e_perm is uncertain. When we use it with '|' operation,
value of perm may be wrong. We should initialize it first.
Change-Id: I232fcb1723d26c5bbe0604705d12ae01fd9d886d
Signed-off-by: Luo Muyao <luo.muyao(a)zte.com.cn>
---
M src/FSAL/posix_acls.c
1 file changed, 1 insertion(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/49/493749/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/493749
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I232fcb1723d26c5bbe0604705d12ae01fd9d886d
Gerrit-Change-Number: 493749
Gerrit-PatchSet: 1
Gerrit-Owner: MuYao Luo <luo.muyao(a)zte.com.cn>
Gerrit-MessageType: newchange
5 months, 2 weeks
frequent failures with PROXY FSAL
by Todd Pfaff
Some of you will likely recall my recent posts in the support list with
subjects:
- consistently reproduceable problem with kvm guest booting root
filesystem via nfs-ganesha 2.8 proxy fsal
- questions about stability of nfs-ganesha versions and PROXY FSAL
I have since moved to using nfs-ganesha next branch version 4-dev.17 and I
can reproduce a failure on demand as described in more detail in github
issue: https://github.com/nfs-ganesha/nfs-ganesha/issues/580.
I'm wondering if there's anyone working on PROXY FSAL development who
would like to work with me on further diagnosing this issue. I would
really like to be able to help to solve this since, other than this
significant problem, nfs-ganesha with the PROXY FSAL is working well.
cheers,
Todd
5 months, 2 weeks
Announce Push of V4-dev.18
by Frank Filz
Branch next
Tag:V4-dev.18
Merge Highlights
* MDCACHE - Fix cache trust when file is modified during getattr
* From 2.8 onwards, ASAN not working for libganesha_nfsd
* Do not downgrade on reopen.
* Clean up memory leaks and logging in PROXY_V#
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
64f0146 Frank S. Filz V4-dev.18
5883f1a Solomon Boulos Fix memory leaks in V3 proxy.
89adf33 Solomon Boulos Make NFS v3 Proxy much less noisy.
61c83b2 Björn Fischer Do not downgrade on reopen. Fixes
https://github.com/nfs-ganesha/nfs-ganesha/issues/577
94a7bf1 ashish.sangwan From 2.8 onwards, ASAN not working for
libganesha_nfsd
2673ec9 Yoni Knobil MDCACHE - Fix cache trust when file is modified during
getattr
5 months, 2 weeks
