Hi,

We have our own FSAL that runs in the following version of NFS ganesha 
on a CentOS system. I have been trying to locate a crash for the last 
few days but with no progress. Any help in this matter will be greatly 
appreciated.

# rpm -qa | grep -i ganesha
nfs-ganesha-2.2.0-6.el7.x86_64
nfs-ganesha-utils-2.2.0-6.el7.x86_64
nfs-ganesha-debuginfo-2.2.0-6.el7.x86_64
#

# uname -a
Linux vcd-test1 3.10.0-327.3.1.el7.x86_64 #1 SMP Wed Dec 9 14:09:15 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux
#

We have been having a crash when running ls -lR for a long periods of 
time (over 1+ hours). To make the crash earlier, we reduced the inode 
cache to 1 by introducing the following configuration parameter.

CACHEINODE
{
         Entries_HWMark = 1;
}

With this change, I am able to get the crash in two ls commands with the 
following steps:
1. mount <ganesha-remore-fs> /mnt
2. cd /mnt
3. ls
4. cd var
5. ls (ganesha crashes)

It seems to me that the somehow the entry obtained from the cache has 
the wrong file handle for var directory. Because, I checked the FH in 
debugger and it has some FH values that seems wrong.

The problematic dir_entry is retrieved at the following line in 
src/Protocols/NFS/nfs3_readdirplus.c

     188         dir_entry = 
nfs3_FhandleToCache(&(arg->arg_readdirplus3.dir),
     189 &(res->res_readdirplus3.status        ),
     190                                           &rc);

Here is the stack trace.

(gdb) where
#0  copy_ganesha_fh (dst=0x7fe602ffd700, src=0x7fe60a825708) at export.c:66
#1  0x00007fe62d5f2699 in create_handle (export_pub=0x7fe60a81f290,
     fh_desc=0x7fe60a825710, pub_handle=0x7fe602ffd7b0) at export.c:136
#2  0x00007fe631d7b7ae in cache_inode_get_keyed (key=0x7fe60a825700,
     flags=<optimized out>, status=0x7fe602ffd82c)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/cache_inode/cache_inode_get.c:312
#3  0x00007fe631d771c6 in cache_inode_lookupp_impl (entry=0x7fe60a825580,
     parent=0x7fe602ffd908)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/cache_inode/cache_inode_lookupp.c:110
#4  0x00007fe631d77883 in cache_inode_lookupp (entry=0x7fe60a825580,
     parent=0x7fe602ffd908)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/cache_inode/cache_inode_lookupp.c:172
#5  0x00007fe631d113a8 in nfs3_readdirplus (arg=<optimized out>,
     worker=<optimized out>, req=<optimized out>, res=0x7fe601014140)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/Protocols/NFS/nfs3_readdirplus.c:268
#6  0x00007fe631d032a8 in nfs_rpc_execute (req=0x7fe60701c2c0,
     worker_data=0x7fe60100e180)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/MainNFSD/nfs_worker_thread.c:1268
#7  0x00007fe631d04dac in worker_run (ctx=0x7fe62de7da80)
     at 
/usr/src/debug/nfs-ganesha-2.2.0/src/MainNFSD/nfs_worker_thread.c:1535
#8  0x00007fe631da1a89 in fridgethr_start_routine (arg=0x7fe62de7da80)
     at /usr/src/debug/nfs-ganesha-2.2.0/src/support/fridgethr.c:562
#9  0x00007fe630045df5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007fe62f7151ad in clone () from /lib64/libc.so.6
(gdb)

Thank you

-- 
Varghese Devassy
v_deva...@yahoo.com


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to