ganesha_mgr add_export command returning premature success when underlying storage is slow
by Sandeep Nashikkar
Hello
We are seeing issue as following:
1. We are using our own FSAL with ganesha version 2.8.2 which eventually performs operation on underlying storage through a wrapper layer.
2. We perform add_export programmatically when required. When add_export command tries to lstat, sometimes the underlying storage takes time to return the attributes. Here is the stack where it gets stuck for some time:
#5 0x00007fdc9d24ea0f in lookup_path () from /usr/lib64/ganesha/libfsaltdfs.so
#6 0x000000000053f719 in mdcache_lookup_path (exp_hdl=0x7fdbfa43d900, path=0x7fdbfa40f200 "/Chk1234", handle=0x7fdbfc0daac8, attrs_out=0x0) at /usr/src/debug/nfs-gan
esha-2.6.3/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1697
#7 0x0000000000504454 in init_export_root (export=0x7fdbfa435448) at /usr/src/debug/nfs-ganesha-2.6.3/support/exports.c:2253
#8 0x00000000005029c2 in export_commit_common (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160, commit_type=add_export) at /us
r/src/debug/nfs-ganesha-2.6.3/support/exports.c:1235
#9 0x0000000000502e27 in add_export_commit (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.6
.3/support/exports.c:1351
#10 0x000000000055832b in proc_block (node=0x7fdbfa4331a0, item=0x7e51a8 <add_export_param+8>, link_mem=0x0, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.
6.3/config_parsing/config_parsing.c:1362
#11 0x0000000000559116 in load_config_from_node (tree_node=0x7fdbfa4331a0, conf_blk=0x7e51a0 <add_export_param>, param=0x0, unique=false, err_type=0x7fdbfc0db160) at
/usr/src/debug/nfs-ganesha-2.6.3/config_parsing/config_parsing.c:1862
#12 0x0000000000518d42 in gsh_export_addexport (args=0x7fdbfc0db220, reply=0x7fdc97bf5180, error=0x7fdbfc0db270) at /usr/src/debug/nfs-ganesha-2.6.3/support/export_mg
r.c:1038
#13 0x000000000055330b in dbus_message_entrypoint (conn=0x7fdc97aaa0c0, msg=0x7fdbfa42a440, user_data=0x7e5ff0 <export_interfaces>) at /usr/src/debug/nfs-ganesha-2.6.
3/dbus/dbus_server.c:564
#14 0x00007fdc9ca50276 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3
#15 0x00007fdc9ca41b29 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x00007fdc9ca41e42 in _dbus_connection_read_write_dispatch () from /lib64/libdbus-1.so.3
#17 0x0000000000553ed9 in gsh_dbus_thread (arg=0x0) at /usr/src/debug/nfs-ganesha-2.6.3/dbus/dbus_server.c:796
#18 0x00007fdc9b429e25 in start_thread () from /lib64/libpthread.so.0
#19 0x00007fdc9aae6bad in clone () from /lib64/libc.so.6
1. Despite the lstat getting stuck, add_export command returns prematurely in 30-40 seconds or so and return code is success. This is not expected.
2. This causes subsequent mount to fail since the export is not actually ready for the mount (init_export_root not being complete)
Can someone help here to understand why dbus interface returns success? Is this known issue? How can we fix this behavior?
Can we rather have a library interface to create/delete/update exports rather than relying on ganesha_mgr python script and dbus interface?
Thanks
Sandeep
4 years
Change in ...nfs-ganesha[next]: LIZARDFS: fix compile issues
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525418 )
Change subject: LIZARDFS: fix compile issues
......................................................................
LIZARDFS: fix compile issues
Change-Id: Id833b9fee6400029ecc884fae43ba6a58f1fd731
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/FSAL/FSAL_LIZARDFS/ds.c
M src/FSAL/FSAL_LIZARDFS/export.c
2 files changed, 2 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/18/525418/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525418
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: Id833b9fee6400029ecc884fae43ba6a58f1fd731
Gerrit-Change-Number: 525418
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
Gerrit-MessageType: newchange
4 years
FSAL_LIZARDFS
by Frank Filz
Patryk, Piotr,
I'm making some changes to the FSAL API with regards to managing file
descriptors (fsal_fd). FSAL_LIZARDFS has an odd bit on opening fd where
there is a no_access_check or after_mknod bool which if TRUE you add O_CREAT
to the posix flags. I'm trying to understand when that is actually necessary
because it seems to be set to true anytime the FSAL commonlib code calls
open_func which may not be right if commonlib is calling open_func in more
situations.
I'd love to have a chat with you folks either via e-mail, or on IRC.
Thanks
Frank Filz
4 years, 1 month
