10:22 a.m.
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