On Fri, Jan 07, 2011 at 03:47:34PM +1100, Nick Piggin wrote: > No, you misunderstand 1. I am saying they should be treated as > WB_SYNC_NONE. > > In fact 2 would cause much more IO, because dirty writeout would > never clean them so it will just keep writing them out. I don't > know how 2 could be feasible. WB_SYNC_NONE means ->write_inode behaves non-blocking. That is we do not block on memory allocations, and we do not take locks blocking. Most journaling filesystems currently take the easy way out an make it a no-op due to that, but take a look at XFS how complicated it is to avoid the blocking if you want a non-noop implementation. > So, back to my original question: what is the performance problem > with treating write_inode as WB_SYNC_NONE, and then having .fsync > and .sync_fs do the integrity? See above - we'll block in the flusher thread and cause it to stall, which is really nasty as it does all data I/O writeback. The salling may also block sync() although I don't think it's as important there. -- 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
