[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] Possible lockup with 2.6.19
From:       Bernd Schubert <bernd-schubert () gmx ! de>
Date:       2007-03-28 20:17:51
Message-ID: eueija$srr$1 () sea ! gmane ! org
[Download RAW message or body]

David Shaw wrote:

> On Wed, Mar 28, 2007 at 02:30:01PM +0200, Bernd Schubert wrote:
>> David Shaw wrote:
>> 
>> > On Thu, Mar 15, 2007 at 12:31:16PM +0100, Miklos Szeredi wrote:
>> >> > I'm using fuse 2.6.3 on a 2.6.19 kernel (from Fedora core 6:
>> >> > 2.6.19-1.2911.fc6PAE), and exporting the fuse filesystem via NFS.
>> >> > 
>> >> > There seem to be two variations of what happens next:
>> >> > 
>> >> > 1) Under heavy read load, all of the nfsd processes end up in D
>> >> > state,
>> >> > and stay there forever.  Nothing logged about the problem.
>> >> 
>> >> Output of SysRq-t would be useful.
>> > 
>> > An update for this: the SysRq-t showed this was unrelated to fuse
>> > itself.  Rather, it was an XFS filesystem bug.  Basically, if you use
>> > sendfile() from a multithreaded program on a file in an XFS
>> > filesystem, you have a reasonable chance of locking that thread.  So
>> > our fuse filesystem was waiting for that data, and nfsd was waiting
>> > for fuse, and the NFS client was waiting for nfsd....  a nice
>> > multilevel freeze.
>> 
>> Do you have a solution or a xfs patch?
>> After updating the system of my former group from Sarge to Etch
>> unionfs-fuse went into a multithreading related deadlock. Until I read
>> your mail I thought it would be glibc related, but your mail reminded me
>> that the filesystem was converted from reiserfs to xfs and so might be a
>> xfs problem as well.
> 
> Unfortunately, I don't have a solution, but I did report it to SGI.
> It's very repeatable.  As a temporary workaround I just replaced
> sendfile() with a read()/write() solution when running on XFS, as only
> sendfile() seems to trigger the lockup.

Thanks. Another question, where is sendfile in your case actually called? In
your filesystem or in fuse or in the libc?
I just grepped the sources of fuse there is a reference to
generic_file_sendfile, though I don't find the definition of this function.
In unionfs-fuse sendfile() is not used. Thinking a bit longer about it after
work, I'm not sure anymore, if our threading problem is at all related - if
unionfs-fuse is statically linked against the libc of Sarge, the problem
does not happen. However, it still might be that the libc of Etch is using
sendfile() and the libc of Sarge isn't.

Thanks,
Bernd



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]