Finally got around to going through latest data. Seems like we lost all the random write performance gains. Creates are better, but total regression on the random workload. Sequential reads seem to have dropped as well. Results are uploading now. http://btrfs.boxacle.net/repository/raid/history/History.html These are for RAID only as single disk system still having issues completing btrfs runs. Also, missing oprofile duw to oprofile causing an NMI and killing the system. Chris, this was built on 7/6, but I see no new changes sine 7/2/. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 20, 2009 at 08:11:42AM -0500, Steven Pratt wrote:> Finally got around to going through latest data. Seems like we lost all > the random write performance gains. Creates are better, but total > regression on the random workload. Sequential reads seem to have > dropped as well.Interesting, was this filesystem freshly created? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason wrote:> On Mon, Jul 20, 2009 at 08:11:42AM -0500, Steven Pratt wrote: > >> Finally got around to going through latest data. Seems like we lost all >> the random write performance gains. Creates are better, but total >> regression on the random workload. Sequential reads seem to have >> dropped as well. >> > > Interesting, was this filesystem freshly created? >Yes, alway mkfs before the runs. Steve> -chris >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2009/7/20 Steven Pratt <slpratt@austin.ibm.com>:> Finally got around to going through latest data. Seems like we lost all the > random write performance gains. Creates are better, but total regression on > the random workload. Sequential reads seem to have dropped as well. > > Results are uploading now. > http://btrfs.boxacle.net/repository/raid/history/History.html > > These are for RAID only as single disk system still having issues completing > btrfs runs. Also, missing oprofile duw to oprofile causing an NMI and > killing the system. > > Chris, this was built on 7/6, but I see no new changes sine 7/2/. > Steve > >The output of ffsb in the latest 128 threads random odirect write benchmark was .... checking existing fs: /mnt/ffsb1 fs setup took 6 secs Syncing()...2 sec .... The corresponding output on 30 June was .... creating new fileset /mnt/ffsb1 fs setup took 847 secs Syncing()...1 sec .... It seems the filesystem used in the latest benchmark wasn''t freshly created. Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Yan Zheng wrote:> 2009/7/20 Steven Pratt <slpratt@austin.ibm.com>: > >> Finally got around to going through latest data. Seems like we lost all the >> random write performance gains. Creates are better, but total regression on >> the random workload. Sequential reads seem to have dropped as well. >> >> Results are uploading now. >> http://btrfs.boxacle.net/repository/raid/history/History.html >> >> These are for RAID only as single disk system still having issues completing >> btrfs runs. Also, missing oprofile duw to oprofile causing an NMI and >> killing the system. >> >> Chris, this was built on 7/6, but I see no new changes sine 7/2/. >> Steve >> >> >> > > The output of ffsb in the latest 128 threads random odirect write benchmark was > .... > checking existing fs: /mnt/ffsb1 > fs setup took 6 secs > Syncing()...2 sec > .... > > The corresponding output on 30 June was > .... > creating new fileset /mnt/ffsb1 > fs setup took 847 secs > Syncing()...1 sec > .... > > It seems the filesystem used in the latest benchmark wasn''t freshly created. >Yes, the older (better) random write performance did indeed recreate the files before the test. Thanks for catching this. I had 2 job files, 1 for just btrfs and 1 for all file systems and the reuse flag is different between them. Please ignore this regression. I will re-run without the reuse flag and expect things to be similar. This does indicate that btrfs degrades quite rapidly under random write, but that is a separate topic. Steve> Yan, Zheng >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html