On Mon, Mar 12, 2007 at 11:36:16PM +0100, Miklos Szeredi wrote: > I'll try to explain the reason for the deadlock first. Ah, thanks for that. > > IIUC, your problem is that there's another bdi that holds all the > > dirty pages, and this throttle loop never flushes pages from that > > other bdi and we sleep instead. It seems to me that the fundamental > > problem is that to clean the pages we need to flush both bdi's, not > > just the bdi we are directly dirtying. > > This is what happens: > > write fault on upper filesystem > balance_dirty_pages > submit write requests > loop ... Isn't this loop transferring the dirty state from the upper filesystem to the lower filesystem? What I don't see here is how the pages on this filesystem are not getting cleaned if the lower filesystem is being flushed properly. I'm probably missing something big and obvious, but I'm not familiar with the exact workings of FUSE so please excuse my ignorance.... > ------- fuse IPC --------------- > [fuse loopback fs thread 1] This is the lower filesystem? Or a callback thread for doing the write requests to the lower filesystem? > read request > sys_write > mutex_lock(i_mutex) > ... > balance_dirty_pages > submit write requests > loop ... write requests completed ... dirty still over limit ... > ... loop forever Hmmm - the situation in balance_dirty_pages() after an attempt to writeback_inodes(&wbc) that has written nothing because there is nothing to write would be: wbc->nr_write == write_chunk && wbc->pages_skipped == 0 && wbc->encountered_congestion == 0 && !bdi_congested(wbc->bdi) What happens if you make that an exit condition to the loop? Or alternatively, adding another bit to the wbc structure to say "there was nothing to do" and setting that if we find list_empty(&sb->s_dirty) when trying to flush dirty inodes." [ FWIW, this may also solve another problem of fast block devices being throttled incorrectly when a slow block dev is consuming all the dirty pages... ] Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
