Ted Ts'o wrote: > On Fri, Oct 22, 2010 at 04:45:17PM -0500, Eric Sandeen wrote: >> As pointed out in a prior patch, updating the mapping's >> writeback_index based on pages written isn't quite right; >> what the writeback index is really supposed to reflect is >> the next page which should be scanned for writeback during >> periodic flush. >> >> As in write_cache_pages(), write_cache_pages_da() does >> this scanning for us as we assemble the mpd for later >> writeout. If we keep track of the next page after the >> current scan, we can easily update writeback_index without >> worrying about pages written vs. pages skipped, etc. >> >> Without this, an fsync will reset writeback_index to >> 0 (its starting index) + however many pages it wrote, which >> can mess up the progress of periodic flush. >> >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > > Have you done any benchmarks with and without this patch series? > > Say, compilebench on a used and mildly fragmented file system? > > - Ted Not compilebench specifically, but I did do some benchmarking with out of cache buffered IO; to be honest I didn't see striking performance differences, but I did see the writeback behave better in terms of not wandering all over, even if it might recover well. I can try compilebench; do you have specific concerns? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
