Re: Random write regression
2009/7/20 Steven Pratt slpr...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random write regression
Yan Zheng wrote: 2009/7/20 Steven Pratt slpr...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Random write regression
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random write regression
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
