On Fri, May 13, 2011 at 10:56:08AM +0800, Wu Fengguang wrote: > On Fri, May 13, 2011 at 06:40:13AM +0800, Dave Chinner wrote: > > On Thu, May 12, 2011 at 09:57:07PM +0800, Wu Fengguang wrote: > > > sync(2) is performed in two stages: the WB_SYNC_NONE sync and the > > > WB_SYNC_ALL sync. Tag the first stage with wbc.tagged_sync and do > > > livelock prevention for it, too. > > > > > > Note that writeback_inodes_sb() is called by not only sync(), they are > > > treated the same because the other callers also need livelock prevention. > > > > > > Impact: It changes the order in which pages/inodes are synced to disk. > > > Now in the WB_SYNC_NONE stage, it won't proceed to write the next inode > > > until finished with the current inode. > > > > What about all the filesystems that implement their own > > .writepages()/write_cache_pages() functions or have > > have special code that checks WB_SYNC_ALL in .writepages (e.g. gfs2, > > ext4, btrfs and perhaps others). Don't they all need to be aware of > > this tagged_sync field? > > Right, good point. Currently only ext4 is updated. The other > filesystems --- afs, btrfs, cifs, gfs2 --- do not even use > PAGECACHE_TAG_TOWRITE for livelock prevention. My plan was to add > PAGECACHE_TAG_TOWRITE and tagged_sync code to them as the next step, > when tagged_sync is accepted and proved to work fine. Where "proved to work fine" can mean "caused regressions for certain filesystems"? I mean, for btrfs it means that the bio is submitted with WRITE rather than WRITE_SYNC, which causes subtle changes of behaviour in the elevator. that could cause strange regressions that are very hard to isolate. Hence regardless of whether filesystems use PAGECACHE_TAG_TOWRITE or not, filesystems are checking for synchronous writeback for a reason. If we now have two different ways of signalling sync writeback they need to know about them. Which just raised the question in my mind - why did you add a new field rather than a new sync_mode definition? After all, this is a new sync control, and it seems clumsy to me to have two separate control fields for defining sync behaviour... 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
