From: Miklos S. <mi...@sz...> - 2007-09-11 17:12:14
|
> This looks similar to my problem and I am wondering if it is or is not. > > Under uClibc instead of glibc, a deadlock occurs 100% of the time on all fuse > mounted filesystems. > > The mount works fine, but and read operation on the filesystem causes the > application performing the read to deadlock. The only way to get back control > to that particular terminal would be to use another one and killall -9 on > something such as sshfs. > > an example sshfs user@localhost:/home/user/Desktop/ /home/user/test/ > Mount would be successful. > > Running df anywhere would deadlock: > # df > > Running ls /home/user/test/ would deadlock > # ls /home/user/test/ > > Pressing the TAB key to tab complete that address would deadlock when I press > TAB at this point: > # /home/user/ > > Any form of reading the mounted directory, its contents, or the mount itself > will result in a deadlock. > > In the past, I was able to workaround the problem by removing the following > lines of code from lib/fuse_lowlevel.c: > __asm__(".symver fuse_reply_statfs_compat,fuse_reply_statfs@FUSE_2.4"); > __asm__(".symver fuse_reply_open_compat,fuse_reply_open@FUSE_2.4"); > __asm__(".symver fuse_lowlevel_new_compat,fuse_lowlevel_new@FUSE_2.4"); > > This is no longer the case, removing it no longer prevents the problem. > > Any ideas/help? Is this the same problem? It's probably something completely different. What is the CPU usage when the filesystem locks up? Miklos |