lkml.org 
[lkml]   [2013]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: jbd2: don't wake kjournald unnecessarily
From
Date
On Mon, 2013-01-21 at 15:28 +0100, Sedat Dilek wrote:
> On Mon, Jan 21, 2013 at 3:07 PM, Jan Kara <jack@suse.cz> wrote:

> > Well, I think the outputs make it pretty clear. /dev/loop0 is a mounted
> > image from fuse filesystem. Fuse daemon making filesystem accessible gets
> > frozen before /dev/loop0 gets fully written out and so jbd2 journal thread
> > hangs. Maybe Miklos (added to CC) could fill in some details / ideas but I
> > think the setup like you have never really worked...
> >
>
> Thank you for the explanations.
> Before doing some patches for Linux Test Project and replying to
> LLVMLinux I was reflecting about FUSE when saw the 'df -h -T' line.
> You might be right, that pm_test/freezer could never be OK here.
> I wantend to test against Linux v3.8-rc4 to be sure.
> Anyway, thanks for sharing your thoughts with me!

There are several problems with this setup. Loop over fuse has always
been problematic because of interaction with the memory management.
E.g. the kernel is trying to allocate memory and is writing out dirty
pages to the loop device then that write ends up in the userspace
filesystem process which may want to allocate additional memory to
complete the write. This may end up deadlocking the writeout, which is
not good. So loop over fuse (for write) is not a good idea in any case.

One way to get around this limitation is to use mountlo, which does a
loop mount in userspace using UML and fuse. That will probably be
better.

Unfortunately fuse has a bad interaction with the freezer as well. The
reason for that is the freezer wants all syscalls to finish but with a
frozen userspace a fuse daemon will not be able to complete the work
necessary to finish those syscalls. We thought about this long and hard
and there are no easy solutions. We can allow the freezer to proceed
for cases when the syscall is directly waiting for a fuse filesystem
daemon reply. But the syscall may be waiting for the filesystem daemon
indirectly, e.g. sleeping on i_mutex, and that's rather more difficult
to fix. It's not impossible but it's a big project.

To conclude: writable loop over fuse is broken and was always broken,
it should not be used. Other solutions should work better but fuse is
currently not

Thanks,
Miklos




\
 
 \ /
  Last update: 2013-01-21 19:21    [W:0.090 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site