Re: [fuse-devel] FW: Problem with concurrent ls calls to a basic fuse device

[John M. <mu...@no...>]

Steven wrote:
> What I'm seeing with the trace is that the hang occurs directly after a
> call to getattr has finished. Running the device in debug mode shows
> that the getattr has completed successfully, but it then doesn't go on
> to call either opendir or readdir, and at this point the hang could
> occur before either of those calls.
>   
Interesting that there should be a problem with getattr. Are you using
SMP machines?

I have the attached series of patches against 2.5.3 which correct the
problems with FUSE and the kernel NFS server. The lock-ups in that
scenario are similar to those found with multiple concurrent 'ls' on the
same directory, in an SMP environment.

The problem occurs because FUSE modifies some of the inode data
structures in non-write operations such as getattr without taking the
inode semaphore, and this is a problem for the NFS server, and also
between threads running through fuse.

The patches attached are a the effort of debugging by myself, Sean
Kormilo, and Matt Maynard. We have not released them until now for a few
reasons:
1. We weren't confident that they solved all locking issues.
2. They don't apply against the CVS head.
3. I'm not sure that they are optimal; we may have been over zealous
with our locks.
4. I haven't had time to fix the above two problems (I will have time in
about 3 months).
5. Miklos has stated many times that he doesn't think knfsd and FUSE
should mix.

The first patch, 0150-fuse_ll_process.patch, is something that is
already included in 2.6.0, and used by the next patch.

(This message was initially too large for fuse-devel, so I split it into 
two. The second posting will contain the 0150-fuse_ll_process.patch, 
which was posted previously in this mailing list.)

The second patch, 0200-fuse-2.5.1-ilookup.patch, implements additional
functions required by the NFS server; lookup by inode number only, and
lookup an inode's parent. My file-system implementation is inode-based,
so we did not implement these functions within the fuse.c. Also, given
that inode numbers returned by fuse.c are not consistent between mounts,
it doesn't make sense to implement them. For NFS to work correctly, a
file-system which returns consistent and unique inode numbers is required.

The third patch, 0300-fuse-inode-locking.patch, implements the inode
locking required to correct the problems with the NFS server, and ls.

Anyways, that said, there they are. If they don't solve your problem,
then you can safely ignore this e-mail. Otherwise, I will endeavor to
make these patches more acceptable to Miklos, and perhaps they can be
included in a future release.

John.

-- 
John Muir
NORTEL
mu...@no...