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