On Sat, Dec 08, 2012 at 07:12:04AM -0500, Christoph Hellwig wrote: > On Fri, Dec 07, 2012 at 11:42:55AM +1100, Dave Chinner wrote: > > The problem wth doing this is that the sync can delay the freeze > > process by quite some time under the exact conditions you describe. > > If you want freeze to take effect immediately (i.e instantly stop > > new modifications), then adding a sync will break this semantic. > > THere are existing users of freeze that require this behaviour... > > But that's only because he uses the big hammer sync_filesystem() which > actually waits for I/O completion. I agree that this is a bad idea, > but if we'd just do a writeback_inodes_sb() call in this place that > starts asynchronous writeout I think everyone would benefit. The problem with that is that async writeback will block on IO submission as soon as the disk backs up on congestion. It's effectively still waiting on IO completions to occur, only now indirectly through the request queue submission process. Hence I think for the heavily loaded situations that are causing freeze latency related issues, sync or async pre-flushes are going to cause exactly the same delays to freezing writes.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
