Random write regression

Random write regression

[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.

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

Re: Random write regression

[Chris Mason]

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

Re: Random write regression

[Steven Pratt]

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
>   

Re: Random write regression

[Yan Zheng]

2009/7/20 Steven Pratt <slpratt@austin.ibm.com>:
> Finally got around to going through latest data. =A0Seems like we los=
t all the
> random write performance gains. =A0Creates are better, but total regr=
ession on
> the random workload. =A0Sequential reads seem to have dropped as well=
=2E
>
> 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
> btrfs runs. =A0Also, 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 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Random write regression

[Steven Pratt]

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
>