Jan Kara <j...@suse.cz> writes: >> I'm not sure what you meant though. What is the difference with ignoring >> WBC_SYNC_NONE? > When you completely ignore WB_SYNC_NONE writeback, you'll soon drive the > machine close to dirty limits and processes dirtying pages will get > throttled. Because flusher threads won't be able to write pages - they > do WB_SYNC_NONE writeback when we have too many dirty pages - processes > will be throttled until somebody calls sync(1) or someone writes the data > for some other reason... So I suspect things won't really work as you > expect.
I think you know how to solve it though. You can add the periodic flush in own task. And you can check bdi->dirty_exceeded in any handlers. Well, ok. The alternative plan but more bigger change is to add the handler to writeback task path. This would be better way, and core should be able to request to flush with usual way (I guess this is what you are concerning). And I believe some FS can implement the simpler and more efficient writeback path. But this would look like what reiserfs4 was submitted in past (before bdi was introduced), and unfortunately never accepted though. Since situation was changed, will we accept it? OK, why my FS requires it? Because basic strategy try to keep the consistency of user view, not only internal metadata consistency. I.e. it works like to flush the snapshot of user view. So, flushing metadata/data by arbitrary order like current writeback task does is unacceptable (of course, except request by user). And writeback task will never know the correct order of FS. Thanks. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/