January 2019 - Support - NFS Ganesha List Archives

NFS4 reexporter question
by Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] 08 Feb '19

08 Feb '19

Hello, I've built nfs-ganesha v2.7.1, and am trying to use the PSEUDO FSAL to reexport an nfs4 mounted directory from the ganesha server to a client. I used the base ganesha.conf (uncommenting out stuff I needed), and followed the examples in /usr/share/doc/packages/ganesha/config_samples/. The mount command on the client succeeds but when I do an ls in the mountpoint dir, there's nothing there. One issue is the client is also mounting the filesystem directly from the same place the ganesha server is, but I didn't think that mattered. I can send config files if needed. Please help me get this working. Thanks. -Jeff

5 17

Some errors starting ganesha - ceph
by Oscar Segarra 05 Feb '19

05 Feb '19

Hi, I'm running nfs-ganesha from docker container. It seems work perfectly, nevertheless when I start the server I get the following messages: Bootstrapping Ganesha NFS config, Bootstrapping CA cert, Skipping boostraping idmap config, Starting rpcbind, Starting rpc.statd, Starting sssd, Starting dbus, Starting Ganesha NFS, 28/01/2019 23:15:17 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] main :MAIN :EVENT :ganesha.nfsd Starting: Ganesha Version 2.7.1, 28/01/2019 23:15:17 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_set_param_from_conf :NFS STARTUP :EVENT :Configuration file successfully parsed, 28/01/2019 23:15:17 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] init_server_pkgs :NFS STARTUP :EVENT :Initializing ID Mapper., 28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] init_server_pkgs :NFS STARTUP :EVENT :ID Mapper successfully initialized., 28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_start_grace :STATE :EVENT :NFS Server Now IN GRACE, duration 90, 28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] lower_my_caps :NFS STARTUP :EVENT :CAP_SYS_RESOURCE was successfully removed for proper quota management in FSAL, 28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] lower_my_caps :NFS STARTUP :EVENT :currenty set capabilities are: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip, *28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Init_svc :DISP :CRIT :Cannot acquire credentials for principal nfs,* 28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Init_admin_thread :NFS CB :EVENT :Admin thread initialized, *28/01/2019 23:15:18 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_rpc_cb_init_ccache :NFS STARTUP :EVENT :Callback creds directory (/var/run/ganesha) already exists,* *28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_rpc_cb_init_ccache :NFS STARTUP :WARN :gssd_refresh_krb5_machine_credential failed (-1765328160:0),* 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :Starting delayed executor., 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :9P/TCP dispatcher thread was started successfully, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :gsh_dbusthread was started successfully, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :admin thread was started successfully, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :reaper thread was started successfully, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_Start_threads :THREAD :EVENT :General fridge was started successfully, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[_9p_disp] _9p_dispatcher_thread :9P DISP :EVENT :9P dispatcher started, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] rpc :TIRPC :EVENT :svc_rqst_hook_events: 0x4b7cb80 fd 1024 xp_refcnt 1 sr_rec 0x4af76d0 evchan 2 ev_refcnt 3 epoll_fd 37 control fd pair (35:36) hook failed (9), *28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nsm_connect :NLM :CRIT :connect to statd failed: RPC: Unknown protocol,* *28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nsm_unmonitor_all :NLM :CRIT :Unmonitor all nsm_connect failed,* 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_start :NFS STARTUP :EVENT :-------------------------------------------------, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_start :NFS STARTUP :EVENT : NFS SERVER INITIALIZED, 28/01/2019 23:15:20 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[main] nfs_start :NFS STARTUP :EVENT :-------------------------------------------------, *28/01/2019 23:16:50 : epoch 5c4f7ef5 : vdicube_pub_ceph_nfs : ganesha.nfsd-25[reaper] nfs_lift_grace_locked :STATE :EVENT :NFS Server Now NOT IN GRACE* I'd like to fix them in order to have a clean execution. Is this possible? Any help will be welcome, Thanks a lot. Ó

4 6

KRB5 NFSv4.x ACLs nfs4_setfacl doesn't work as expected
by smirta＠gmx.net 30 Jan '19

30 Jan '19

We have issues with NFSv4 ACLs. When we want to change the ACL on the mountpoint on the client as a domain (freeipa) user, we get bizarre behavior. It works if we set ACLs as root user. We are using a brick formatted as xfs which should support extended attributes but somehow it's not being recognized. Maybe somebody in here could bring us on the right track. At the moment we don't know how to solve this. We are running a gluster environment (V3.12.14) on Centos 7.5.1804 with a separate Ganesha-NFS (V2.5.5) server in a FreeIPA-joined environment. Assuming working ganesha-configuration is in place this can be reproduced as follows: 1) Mount share as root on a client (NFS version doesn't seem to matter, tested with 4.0,4.1,4.2): mount -vvv -t nfs4 -o sec=krb5,rw,acl,timeo=10 myhost.domain.com:/srv/shares /mnt/ 2) Create a file as domain user touch /mnt/test nfs4_getfacl /mnt/test # getfacl returns nothing for a couple of seconds after that nfs4_getfacl /mnt/test A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:tcy 3) After this we try to change the ACL nfs4_setfacl -a "A:g:admins@mydomain.com:rwaDxtcy" "/mnt/test" Failed setxattr operation: Invalid argument This fails and we can see in the ganesha.log on the server 20/06/2018 11:49:37 : epoch 5b2a225d : myhost.mydomain.com : ganesha.nfsd-14820[work-38] glusterfs_set_acl :FSAL :MAJ :failed to set access type posix acl 20/06/2018 11:49:37 : epoch 5b2a225d : myhost.mydomain.com : ganesha.nfsd-14820[work-38] glusterfs_setattr2 :FSAL :CRIT :setattrs failed with error Success and on the gluster server [2018-06-20 09:49:37.673738] I [MSGID: 139001] [posix-acl.c:269:posix_acl_log_permit_denied] 0-myglustervolume-access-control: client: vm-0026.service.int.rabe.ch-14820-2018/06/20-09:46:05:292146-myglustervolume-client-1-0-0, gfid: d0d93931-8915-4a2f-b6be-f53ac154eacf, req(uid:1101,gid:1101,perm:2,ngrps:3), ctx(uid:1101,gid:1101,in-groups:1,perm:000,updated-fop:SETATTR, acl:-) [Permission denied] [2018-06-20 09:49:37.674074] I [MSGID: 115060] [server-rpc-fops.c:899:_gf_server_log_setxattr_failure] 0-myglustervolume-server: 43: SETXATTR /test (d0d93931-8915-4a2f-b6be-f53ac154eacf) ==> glusterfs.posix.acl, client: myhost.mydomain.com-14820-2018/06/20-09:46:05:292146-myglustervolume-client-1-0-0, error-xlator: myglustervolume-access-control [2018-06-20 09:49:37.674090] I [MSGID: 115060] [server-rpc-fops.c:929:server_setxattr_cbk] 0-myglustervolume-server: client: myhost.mydomain.com-14820-2018/06/20-09:46:05:292146-myglustervolume-client-1-0-0, error-xlator: myglustervolume-access-control [Permission denied] Today I have noticed something that I can't understand. xfs should support extended attributes by default but on the gluster-server I can see this error: [2018-12-05 16:30:35.492623] W [posix.c:4929:posix_getxattr] 0-myglustervolume-posix: Extended attributes not supported (try remounting brick with 'user_xattr' flag) [2018-12-05 16:30:35.492649] E [MSGID: 113001] [posix.c:4940:posix_getxattr] 0-myglustervolume-posix: getxattr failed on /srv/gluster/myglustervolume/gb-01/brick/.glusterfs/b8/26/b8264d88-43a9-4a5a-8381-aaa041cd8c9f: system.nfs4_acl [Operation not supported] 4) after a couple of seconds then the permissions are completely removed nfs4_getfacl /mnt/test A::OWNER@:tcy A::GROUP@:tcy A::EVERYONE@:tcy All this works perfectly fine if do it without nfs-ganesha. Mount gluster volume on the server and serve it via nfs. There is a good chance we are doing something fundamentally wrong. We are not looking to get it entirely resolved. But please share your thoughts what's going on here or where we have to look for an issue. Thanks Simon

1 0

does ganesha deny access for unknown UIDs?
by Billich Heinrich Rainer (PSI) 25 Jan '19

25 Jan '19

Hello, a local account on a nfs client couldn’t write to a ganesha nfs export even with directory permissions 777. The solution was to create the account on the ganesha servers, too. Please can you confirm that this is the intended behaviour? is there an option to change this and to map unknown accounts to nobody instead? We often have embedded Linux appliances or similar as nfs clients which need to place some data on the nfs exports using uid/gid of local accounts. We manage gids on the server side and allow NFS v3 client access only. I crosspost this to ganesha support and to the gpfsug mailing list. Thank you, Heiner Billich ganesha version: 2.5.3-ibm028.00.el7.x86_64 the ganesha config CacheInode { fd_hwmark_percent=60; fd_lwmark_percent=20; fd_limit_percent=90; lru_run_interval=90; entries_hwmark=1500000; } NFS_Core_Param { clustered=TRUE; rpc_max_connections=10000; heartbeat_freq=0; mnt_port=33247; nb_worker=256; nfs_port=2049; nfs_protocols=3,4; nlm_port=33245; rquota_port=33246; rquota_port=33246; short_file_handle=FALSE; mount_path_pseudo=true; } GPFS { fsal_grace=FALSE; fsal_trace=TRUE; } NFSv4 { delegations=FALSE; domainname=virtual1.com; grace_period=60; lease_lifetime=60; } Export_Defaults { access_type=none; anonymous_gid=-2; anonymous_uid=-2; manage_gids=TRUE; nfs_commit=FALSE; privilegedport=FALSE; protocols=3,4; sectype=sys; squash=root_squash; transports=TCP; } one export # === START /**** id=206 nclients=3 === EXPORT { Attr_Expiration_Time=60; Delegations=none; Export_id=206; Filesystem_id=42.206; MaxOffsetRead=18446744073709551615; MaxOffsetWrite=18446744073709551615; MaxRead=1048576; MaxWrite=1048576; Path="/****"; PrefRead=1048576; PrefReaddir=1048576; PrefWrite=1048576; Pseudo="/****"; Tag="****"; UseCookieVerifier=false; FSAL { Name=GPFS; } CLIENT { # === ****/X12SA === Access_Type=RW; Anonymous_gid=-2; Anonymous_uid=-2; Clients=X.Y.A.B/24; Delegations=none; Manage_Gids=TRUE; NFS_Commit=FALSE; PrivilegedPort=FALSE; Protocols=3; SecType=SYS; Squash=Root; Transports=TCP; } …. -- Paul Scherrer Institut Heiner Billich System Engineer Scientific Computing Science IT / High Performance Computing WHGA/106 Forschungsstrasse 111 5232 Villigen PSI Switzerland Phone +41 56 310 36 02 heiner.billich(a)psi.ch<mailto:heiner.billich@psi.ch> https://www.psi.ch

2 2

ganesha coredump in mdcache_get_chunk()
by Madhu Thorat 11 Jan '19

11 Jan '19

Hello, Not sure if my previous mail was sent, hence re-sending the mail. We saw a crash at the following line in mdcache_get_chunk() as prev_chunk's dirent list is empty. chunk->reload_ck = glist_last_entry(&prev_chunk->dirents, mdcache_dir_entry_t, chunk_list)->ck; The backtrace of the coredump is at the end of the mail. I could reproduce similar crash by doing the following: 1. In mdcache_readdir_chunked inserted a sleep() after the content_lock is released and before the content_lock is acquired for writing as follows: 2805 again: 2806 /* Get here on first pass, retry if we don't hold the write lock, 2807 * and repeated passes if we need to fetch another chunk. 2808 */ 2809 2810 LogFullDebugAlt(COMPONENT_NFS_READDIR, COMPONENT_CACHE_INODE, 2811 "Readdir chunked next_ck=0x%"PRIx64" look_ck=%"PRIx64, 2812 next_ck, look_ck); 2813 2814 if (look_ck == 0 || 2815 !mdcache_avl_lookup_ck(directory, look_ck, &dirent)) { 2816 fsal_status_t status; 2817 /* This starting position isn't in our cache... 2818 * Go populate the cache and process from there. 2819 */ 2820 if (!has_write) { 2821 /* Upgrade to write lock and retry just in case 2822 * another thread managed to populate this cookie 2823 * in the meantime. 2824 */ 2825 PTHREAD_RWLOCK_unlock(&directory->content_lock); 2826 * sleep(30); // Sleep here* 2827 PTHREAD_RWLOCK_wrlock(&directory->content_lock); 2828 has_write = true; 2829 goto again; 2830 } 2. From 1st client run 'ls' inside a mounted directory for an export. 'ls' is made to wait as there is sleep() in mdcache_readdir_chunked() 3. Immediately from 2nd client remove all the entries inside the mounted directory for the same export. 4. After sleep() time is over, ganesha crashes as the 'prev_chunk' is not valid in mdcache_readdir_chunked() Following is the coredump for reference. The code used was ganesha 2.5 and it has patches for 'readdir' taken from https://github.com/dang/nfs-ganesha/tree/v2.5-readdir, the code for mdcache_readdir_chunked() looks similar to mdcache_readdir_chunked() in 2.8 #0 0x00007fae938dc4ab in raise () from /lib64/libpthread.so.0 #1 0x000000000045549e in crash_handler (signo=11, info=0x7fae25f48eb0, ctx=0x7fae25f48d80) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_init.c:225 #2 <signal handler called> #3 mdcache_get_chunk (parent=0x7faa1001a290, prev_chunk=0x7fade0206350, whence=2147483647) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:909 #4 0x000000000054fbe9 in mdcache_populate_dir_chunk (directory=0x7faa1001a290, whence=2147483647, dirent=0x7fae25f49680, prev_chunk=0x7fade0206350, eod_met=0x7fae25f4967f) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:2659 #5 0x0000000000551767 in mdcache_readdir_chunked (directory=0x7faa1001a290, whence=2147483647, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:3053 #6 0x000000000053f39f in mdcache_readdir (dir_hdl=0x7faa1001a2c8, whence=0x7fae25f49970, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:639 #7 0x00000000004339f3 in fsal_readdir (directory=0x7faa1001a2c8, cookie=2147483647, nbfound=0x7fae25f49e8c, eod_met=0x7fae25f49e8b, attrmask=0, cb=0x495d70 <nfs3_readdir_callback>, opaque=0x7fae25f49e40) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/fsal_helper.c:1502 #8 0x0000000000495b57 in nfs3_readdir (arg=0x7fa8b4f75e80, req=0x7fa8b4f75678, res=0x7faad82c8c70) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/Protocols/NFS/nfs3_readdir.c:289 #9 0x000000000044ccde in nfs_rpc_execute (reqdata=0x7fa8b4f75650) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1290 #10 0x000000000044d4e8 in worker_run (ctx=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1562 #11 0x000000000050c57f in fridgethr_start_routine (arg=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/support/fridgethr.c:550 (gdb) frame 3 (gdb) p *prev_chunk $9 = {chunks = {next = 0x7faad808a570, prev = 0x7fade00000d8}, dirents = {next = 0x7fade0206360, prev = 0x7fade0206360}, parent = 0x0, chunk_lru = {q = {next = 0x0, prev = 0x0}, qid = LRU_ENTRY_L1, refcnt = 0, flags = 0, lane = 534, cf = 0}, reload_ck = 1453366958, next_ck = 0, num_entries = 112} To fix this I have posted a patch: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/440079 Thanks, Madhu Thorat.

1 0

ganesha coredump in mdcache_get_chunk()
by Madhu P Punjabi 11 Jan '19

11 Jan '19

Hello, We saw a crash at the following line in mdcache_get_chunk() as prev_chunk's dirent list is empty. chunk->reload_ck = glist_last_entry(&prev_chunk->dirents, mdcache_dir_entry_t, chunk_list)->ck; The backtrace of the coredump is at the end of the mail. I could reproduce similar crash by doing the following: 1. In mdcache_readdir_chunked inserted a sleep(30) after the content_lock is released and before the content_lock is acquired for writing as follows: 2805 again: 2806 /* Get here on first pass, retry if we don't hold the write lock, 2807 * and repeated passes if we need to fetch another chunk. 2808 */ 2809 2810 LogFullDebugAlt(COMPONENT_NFS_READDIR, COMPONENT_CACHE_INODE, 2811 "Readdir chunked next_ck=0x%"PRIx64" look_ck=%"PRIx64, 2812 next_ck, look_ck); 2813 2814 if (look_ck == 0 || 2815 !mdcache_avl_lookup_ck(directory, look_ck, &dirent)) { 2816 fsal_status_t status; 2817 /* This starting position isn't in our cache... 2818 * Go populate the cache and process from there. 2819 */ 2820 if (!has_write) { 2821 /* Upgrade to write lock and retry just in case 2822 * another thread managed to populate this cookie 2823 * in the meantime. 2824 */ 2825 PTHREAD_RWLOCK_unlock(&directory-> content_lock); 2826 sleep (30); // Sleep here 2827 PTHREAD_RWLOCK_wrlock(&directory-> content_lock); 2828 has_write = true; 2829 goto again; 2830 } 2. From 1st client run 'ls' inside a mounted directory for an export. 'ls' is made to wait as there is sleep() in mdcache_readdir_chunked() 3. Immediately from 2nd client remove all the entries inside the mounted directory for the same export. 4. After sleep() time is over, ganesha crashes as the 'prev_chunk' is not valid in mdcache_readdir_chunked() Following is the coredump for reference. The code used was ganesha 2.5 and it has patches for 'readdir' taken from https://github.com/dang/nfs-ganesha/tree/v2.5-readdir, the code for mdcache_readdir_chunked() looks similar to mdcache_readdir_chunked() in 2.8 #0 0x00007fae938dc4ab in raise () from /lib64/libpthread.so.0 #1 0x000000000045549e in crash_handler (signo=11, info=0x7fae25f48eb0, ctx=0x7fae25f48d80) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_init.c:225 #2 <signal handler called> #3 mdcache_get_chunk (parent=0x7faa1001a290, prev_chunk=0x7fade0206350, whence=2147483647) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:909 #4 0x000000000054fbe9 in mdcache_populate_dir_chunk (directory=0x7faa1001a290, whence=2147483647, dirent=0x7fae25f49680, prev_chunk=0x7fade0206350, eod_met=0x7fae25f4967f) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:2659 #5 0x0000000000551767 in mdcache_readdir_chunked (directory=0x7faa1001a290, whence=2147483647, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:3053 #6 0x000000000053f39f in mdcache_readdir (dir_hdl=0x7faa1001a2c8, whence=0x7fae25f49970, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:639 #7 0x00000000004339f3 in fsal_readdir (directory=0x7faa1001a2c8, cookie=2147483647, nbfound=0x7fae25f49e8c, eod_met=0x7fae25f49e8b, attrmask=0, cb=0x495d70 <nfs3_readdir_callback>, opaque=0x7fae25f49e40) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/fsal_helper.c:1502 #8 0x0000000000495b57 in nfs3_readdir (arg=0x7fa8b4f75e80, req=0x7fa8b4f75678, res=0x7faad82c8c70) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/Protocols/NFS/nfs3_readdir.c:289 #9 0x000000000044ccde in nfs_rpc_execute (reqdata=0x7fa8b4f75650) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1290 #10 0x000000000044d4e8 in worker_run (ctx=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1562 #11 0x000000000050c57f in fridgethr_start_routine (arg=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/support/fridgethr.c:550 (gdb) frame 3 (gdb) p *prev_chunk $9 = {chunks = {next = 0x7faad808a570, prev = 0x7fade00000d8}, dirents = {next = 0x7fade0206360, prev = 0x7fade0206360}, parent = 0x0, chunk_lru = {q = {next = 0x0, prev = 0x0}, qid = LRU_ENTRY_L1, refcnt = 0, flags = 0, lane = 534, cf = 0}, reload_ck = 1453366958, next_ck = 0, num_entries = 112} To fix this I have posted a patch: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/440079 Thanks, Madhu Thorat.

1 0