[lkml]   [2004]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes
Andrew Morton wrote:

> I don't know why the single-stream case would be slower, but the
> two-stream
>case is probably due to writeback changes interacting with a weakness in
>the block allocator. 10 megs/sec is pretty awful either way.
10MB/s is just because I did the test on an old machine, it maxes out at
15MB/s with "hdparm -t".
I didn't want to do it on my main PC because I using it to record a TV
program at the time :-)

>Either way, you have intermingled blocks in the files.
Yes the blocks are intermingled. Thanks for the explanation of the
2.4/2.6 difference.

>Reads will be slower too - you will probably find that reading back a file
Yes reads are 50% for 2 streams, 25% for 4 etc. 2.4 and 2.6 perform the
I did a debugfs "stat" and it clearly shows the fragmented file blocks.

>You can probably address it quite well within the
>application itself by buffering up a good amount of data for each write()
>call. Maybe a megabyte.
Writes in the 256kB - 1MB region do avoid the problem. Unfortunately the
way the application is written it makes this tricky to do. It wants to
write out the data in one frame at a time, typically 10 - 50kB.

>XFS will do well at this.
Yes, both XFS and JFS perform much better. Here is a summary of some
tests done on 2.6, these were done on a faster machine / disk
combination. This was the original test program which also measured the
read speeds, you can get this from

The ext2 result is a bit slow, but ext3 is really bad.

Num streams |1 1 |2 2
Filesystem |Write Read |Write Read
Ext2 |27.7 29.17 | 5.89 14.43
ext3-ordered |25.73 29.21 | 0.48 1.1
Reiserfs |25.31 26.25 | 7.47 13.55
JFS |26.27 26.95 |26.92 28.5
XFS |27.51 26.00 |27.35 27.42

>You might be able to improve things significantly on ext2 by increasing
>EXT2_DEFAULT_PREALLOC_BLOCKS by a lot - make it 64 or 128. I don't recall
>anyone trying that.
I'll give it a go.

>But I must say, a 21x difference is pretty wild. What filesytem was that
>with, and how much memory do you have, and what was the bandwidth of each
>stream, and how much data is the application passing to write()?
The results were from running the test program I attached to the
original email. It was writing 4kB at a time on a ext2 filesystem. It
tries to write the data in a tight loop, taking as much bandwidth as it
can get.

In the real application it records MPEG2 DVB streams from TV and radio.
The bandwidths are as follows:
TV ~ 500kByte/s, in 10 - 50kB blocks (one MPEG frame at a time).
Radio ~ 24kByte/s, in blocks of around 2-4kB.

The write performance is not too critical. Even at 5MB/s I would still
be able to record 10 TV channels.
I wrote the benchmark primarily to see why the read performance was so
bad. I noticed that when I started moving the files between disks the
transfer rate would be really erratic. Sometimes 40MB/s, sometimes 5MB/s.

The worst case that I found was when I record a TV and radio stream
simultaneously. The data blocks are recorded in a patterm of 1 block of
radio data followed by 20 blocks of TV. When I read back the radio
stream I get only 1:20th of the disk performance (1 - 2 MB/s).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.098 / U:26.612 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site