lkml.org 
[lkml]   [2007]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/3] fix illogical behavior in balance_dirty_pages()
On Mon, 26 Mar 2007 11:20:11 +0200 Miklos Szeredi <miklos@szeredi.hu> wrote:

> > > > > It also makes a deadlock possible when one filesystem is writing data
> > > > > through another, and the balance_dirty_pages() for the lower
> > > > > filesystem is stalling the writeback for the upper filesystem's
> > > > > data (*).
> > > >
> > > > I still don't understand this one. I got lost when belatedly told that
> > > > i_mutex had something to do with it.
> > >
> > > This deadlock only happens, if there's some bottleneck for writing
> > > data to the lower filesystem. This bottleneck could be
> > >
> > > - i_mutex, preventing parallel writes to the same inode
> > > - limited number of filesystem threads
> > > - limited request queue length in the upper filesystem
> > >
> > > Imagine it this way: balance_dirty_pages() for the lower filesystem is
> > > stalling a write() because dirty pages in the upper filesystem are
> > > over the limit. Because there's a bottleneck for writing to the lower
> > > filesystem, this is stalling _other_ writes from completing. So
> > > there's no progress in writing back pages from the upper filesystem.
> >
> > You mean that someone is stuck in balance_dirty_pages() against the lower
> > fs while holding locks which prevent writes into the upper fs from
> > succeeding?
> >
> > Draw us a picture ;)
>
> Well, not a picture, but a sort of indented call trace:
>
> [some process, which has a fuse file writably mmaped]
> write fault on upper filesystem
> balance_dirty_pages
> loop...
> submit write requests

This, I assume, is the upper fs

> ---------------------------------
> [fuse loopback fs thread 1]
> read request from /dev/fuse
> sys_write
> mutex_lock(i_mutex)
> ...
> copy data to page cache
> balance_dirty_pages
> loop ...
> submit write requests
> write requests completed ...
> dirty still over limit ...
> ... loop forever
>
> [fuse loopback fs thread 2]
> read request from /dev/fuse
> sys_write
> mute_lock(i_mutex) blocks

And these, I assume, are handling what you term the lower fs.

>
> The lower filesystem (e.g. ext3) has completed the single write
> request that was sent to it, and then it's just looping in
> balance_dirty_pages. The upper (fuse) filesystem has all the dirty
> data (over the threshold), either still dirty or waiting in the
> request queue as writeback.
>
> Does this help?

yup.

Interesting problem. I don't suppose that it'd be appreiated if I were to
commend the use of O_DIRECT for handling the lower fs ;)

Let me think about that a bit, after I've made the latest shitpile people
have inflicted upon me begin to look like it has a chance of compiling.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-26 11:35    [W:0.069 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site