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
Quoted 4 lines · Steven Pratt
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
Quoted 7 lines · Chris Mason
Quoted 2 lines · Steven Pratt
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
Quoted 2 lines
-chris
2009/7/20 Steven Pratt <[email protected]>:
Quoted 1 line
Finally got around to going through latest data. =A0Seems like we los=
t all the
Quoted 1 line
random write performance gains. =A0Creates are better, but total regr=
ession on
Quoted 1 line
the random workload. =A0Sequential reads seem to have dropped as well=
=2E
Quoted 5 lines
Results are uploading now. =A0http://btrfs.boxacle.net/repository/raid/history/History.html
These are for RAID only as single disk system still having issues com=
pleting
Quoted 1 line
btrfs runs. =A0Also, missing oprofile duw to oprofile causing an NMI =
and
Quoted 6 lines
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 bench= mark was
=2E...
checking existing fs: /mnt/ffsb1
fs setup took 6 secs
Syncing()...2 sec
=2E...
The corresponding output on 30 June was
=2E...
creating new fileset /mnt/ffsb1
fs setup took 847 secs
Syncing()...1 sec
=2E...
It seems the filesystem used in the latest benchmark wasn't freshly cre= ated.
Yan, Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 26 lines · Yan Zheng
2009/7/20 Steven Pratt <[email protected]>:
Quoted 7 lines
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.htmlQuoted 9 lines
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
....
Quoted 9 lines
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
Quoted 2 lines
Yan, Zheng