Linux File System Read Write Performance Test

Sarath Pillai's picture

System administrators responsible for handling Linux servers get confused at times when they are told to benchmark a file system's performance. But the main reason that this confusion happens is because, it does not matter whatever tool you use to test the file system's performance, what matter's is the exact requirement.File system's performance depends upon certain factors as follows.

  • The maximum rotational speed of your hard disk
  • The Allocated block size of a file system
  • Seek Time
  • The performance rate of the file system's metadata
  • The type of read/Write

Seriously speaking its wonderful to realize that various different technologies made by different people and even different companies are working together in coordination inside a single box, and we call that box a computer. And its even more wonderful to realize that hard disk's store's almost all the information available in the world in digital format. Its a very complex thing to understand how really hard disks stores our data safely. Explaining different aspects of how a hard disk, and a file system on top of it, work together is beyond the scope of this article(But i will surely give it a try with couple of my posts about themwink)

So Lets begin our tutorial on file system benchmark test.

Its advised that during this file system performance test, you must not run any other disk I/O intensive tasks. Otherwise your results about performance will be heavily deviated. Its better to stop all other process during this test.

The Simplest Performance Test Using dd command

The simplest read write performance test in Linux can be done with the help of dd command. This command is used to write or read from any block device in Linux. And you can do a lot of stuff with this command. The main plus point with this command, is that its readily available in almost all distributions out of the box. And is pretty easy to use.

With this dd command we will only be testing sequential read and sequential write.I will test the speed of my partition /dev/sda1 which is mounted on "/" (the only partition i have on my system)so can write the data to any where in my filesystem to test.

[root@slashroot2 ~]# dd if=/dev/zero of=speetest bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0897865 seconds, 1.2 GB/s
[root@slashroot2 ~]

In the above command you will be amazed to see that you have got 1.1GB/s. But dont be happy thats falsecheeky. Becasue the speed that dd reported to us is the speed with which data was cached to RAM memory, not to the disk. So we need to ask dd command to report the speed only after the data is synced with the disk.For that we need to run the below command.

[root@slashroot2 ~]# dd if=/dev/zero of=speetest bs=1M count=100 conv=fdatasync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 2.05887 seconds, 50.9 MB/s

As you can clearly see that with the attribute fdatasync the dd command will show the status rate only after the data is completely written to the disk. So now we have the actual sequencial write speed. Lets go to an amount of data size thats larger than the RAM. Lets take 200MB of data in 64kb block size.

[root@slashroot2 ~]# dd if=/dev/zero of=speedtest bs=64k count=3200 conv=fdatasync
3200+0 records in
3200+0 records out
209715200 bytes (210 MB) copied, 3.51895 seconds, 59.6 MB/s

 

as you can clearly see that the speed came to 59 MB/s. You need to note that ext3 bydefault if you do not specify the block size, gets formatted with a block size thats determined by the programes like mke2fs . You can verify yours with the following commands.

tune2fs -l /dev/sda1

dumpe2fs /dev/sda1

For testing the sequential read speed with dd command, you need to run the below command as below.

[root@myvm1 sarath]# dd if=speedtest of=/dev/null bs=64k count=24000
5200+0 records in
5200+0 records out
340787200 bytes (341 MB) copied, 3.42937 seconds, 99.4 MB/s

Performance Test using HDPARM

Now lets use some other tool other than dd command for our tests. We will start with hdparm command to test the speed. Hdparm tool is also available out of the box in most of the linux distribution.

[root@myvm1 ~]# hdparm -tT /dev/sda1
 
/dev/sda1:
 Timing cached reads:   5808 MB in  2.00 seconds = 2908.32 MB/sec
 Timing buffered disk reads:   10 MB in  3.12 seconds =   3.21 MB/sec

 

There are multiple things to understand here in the above hdparm results. the -t Option will show you the speed of reading from the cache buffer(Thats why its much much higher).

The -T option will show you the speed of reading without precached buffer(which from the above output is low 3.21 MB/sec as shown above. )

the hdparm output shows you both the cached reads and disk reads separately. As mentioned before hard disk seek time also matters a lot for your speed you can check your hard disk seek time with the following linux command. seek time is the time required by the hard disk to reach the sector where the data is stored.Now lets use this seeker tool to find out the seek time by the simple seek command.

[root@slashroot2 ~]# seeker /dev/sda1
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [81915372 blocks, 41940670464 bytes, 39 GB, 39997 MB, 41 GiB, 41940 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 87 seeks/second, 11.424 ms random access time (26606211 < offsets < 41937280284)
[root@slashroot2 ~]#

its clearly mentioned that my disk did a 86 seeks for sectors containing data per second. Thats ok for a desktop Linux machine but for servers its not at all ok.

Read Write Benchmark Test using IOZONE:

Now there is one tool out there in linux that will do all these test in one shot. Thats none other than "IOZONE". We will do some benchmark test against my /dev/sda1 with the help of iozone.Computers or servers are always purchased keeping some purpose in mind. Some servers needs to be highend performance wise, some needs to be fast in sequencial reads,and some others are ordered keeping random reads in mind. IOZONE will be very much helpful in carrying out large number of permance benchmark test against the drives. The output produced by iozone is too much brief.

The default command line option -a is used for full automatic mode, in which iozone will test block sizes ranging from 4k to 16M and file sizes ranging from 64k to 512M. Lets do a test using this -a option and see what happens.
 
[root@myvm1 ~]# iozone -a /dev/sda1
             Auto Mode
        Command line used: iozone -a /dev/sda1
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.

                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
              64       4  172945  581241  1186518  1563640  877647  374157  484928   240642   985893   633901   652867 1017433  1450619
              64       8   25549  345725   516034  2199541 1229452  338782  415666   470666  1393409   799055   753110 1335973  2071017
              64      16   68231  810152  1887586  2559717 1562320  791144 1309119   222313  1421031   790115   538032  694760  2462048
              64      32  338417  799198  1884189  2898148 1733988  864568 1421505   771741  1734912  1085107  1332240 1644921  2788472
              64      64   31775  811096  1999576  3202752 1832347  385702 1421148   771134  1733146   864224   942626 2006627  3057595
             128       4  269540  699126  1318194  1525916  390257  407760  790259   154585   649980   680625   684461 1254971  1487281
             128       8  284495  837250  1941107  2289303 1420662  779975  825344   558859  1505947   815392   618235  969958  2130559
             128      16  277078  482933  1112790  2559604 1505182  630556 1560617   624143  1880886   954878   962868 1682473  2464581
             128      32  254925  646594  1999671  2845290 2100561  554291 1581773   723415  2095628  1057335  1049712 2061550  2850336
             128      64  182344  871319  2412939   609440 2249929  941090 1827150  1007712  2249754  1113206  1578345 2132336  3052578
             128     128  301873  595485  2788953  2555042 2131042  963078  762218   494164  1937294   564075  1016490 2067590  2559306

           

Note: All the output you see above are in KB/Sec

The first column shows the file size used and second column shows the length of the record used.

Lets understand the output in some of the columns

The third Column-Write:This column shows the speed Whenever a new file is made in any file system under Linux. There is more overhead involved in the metadata storing. For example the inode for the file, and its entry in the journal etc. So creating a new file in a file system is always comparatively slower than overwriting an already created file.

Fourth column-Re-writing:This shows the speed reported in overwriting the file which is already created

Fifth column-Read:This reports the speed of reading an already existing file.

sixth column-Re-Read:This reports the speed of rereading a file which is already read. In all operating system there is disk locations cached for faster access. So Rereading a file which is already read, is faster.

Seventh Column-Random Read:This will show the speed when random area's of a single file is accessed. This is slower at times.

Eighth column-Random Write:random write is similar to random read. But instead will write to an already existing file by accessing random areas in the file.

Ninth Column-Random Mix:This column tells the random read and random write speeds combined together.

Backwards Read: This column reports the speed of doing a backward read. For example start reading from the end to the beginning of the file.

For more information Please reffer to : url=http://www.iozone.org/You can save the output of the iozone using -b option avialable in iozone as follows.

[root@myvm1 ~]# iozone -a -b speedtest.xls

Where "speedtest.xls" is the output file. You can now open this output file in excel sheet using open office and have a complete detailed report regarding the speed test.-s option present in iozone can be used to specify the filesize to be used for iozone test. As shown below.

[root@slashroot2 ~]# iozone -a -s 4048 -i 0

The above command will run the iozone utility with a filesize of 4MB and only will do a write and rewrite test because we have given it 0 option.You can pass numberical options to do only selective tests. Such as 0 for write and rewrite and 1 for 1 read and reread,2 for random read and write etc(you need to use the -i option before the numeric option).

Another tool that can be used for filesystem performance test is bonnie

 

Read Write Performance Test using Bonnie

Bonnie is also a very nice tool that can be used for performance benchmarking the hardisk. It can be installed by enabling the rpmforge repo.Now run the command as shown below for the test. run the command in the directory where your desired partition is mounted. for example am testing the /dev/sda1(which is my /).

[root@slashroot2 ~]# bonnie
Bonnie: Warning: You have 503MiB RAM, but you test with only 100MiB datasize!
Bonnie:          This might yield unrealistically good results,
Bonnie:          for reading and seeking and writing.
Bonnie 1.5: File './Bonnie.4614', size: 104857600, volumes: 1
Writing with putc()...         done:  24712 kiB/s  98.2 %CPU
Rewriting...                   done: 789544 kiB/s  83.3 %CPU
Writing intelligently...       done: 253001 kiB/s  80.5 %CPU
Reading with getc()...         done:  26101 kiB/s  99.5 %CPU
Reading intelligently...       done: 3723094 kiB/s 101.8 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
Estimated seek time: raw 0.006ms, eff 0.001ms

              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB kiB/s %CPU kiB/s %CPU kiB/s %CPU kiB/s %CPU kiB/s %CPU   /sec %CPU
slashr 1* 100 24712 98.2253001 80.5 789544 83.3 26101 99.53723094  102 173145.2 95.2

the final line in the above output shows sequencial output,sequencial input and random seek etc.you need to pass the -y option to sync the data to the disk. You can specify the filesize used to test with -s option.

[root@slashroot2 ~]# bonnie -y -s 1000

 

How to use FIO for IO benchmark Test

Fio is also another nice and small tool that can be used for benchmarking the IO usage of a particular drive. Unlike previous tools we saw, the fio tool does not run with command line options.

A file with full of parameters regarding the type of test is made. And then this file is passed to the "fio" command as an argument.

So lets begin by making our fio test file and its argument.

the file that will be passed as an argument will begin by

; -- start job file -- 

and will end with

; -- end job file --

Lets do a test with FIO and a file with argument as the parameter.

[root@myvm1 sarath]# cat fiotest
; -- start job file --
[random-writers]
rw=randrw
size=50m
numjobs=1
; -- end job file --

The output of the fio command is too much descriptive..but (there is a different documentation altogether for understanding the output for fio command)

The result of the At the end of the fio command with "the argument file" You will see the summery of the test.

Run status group 0 (all jobs):
   READ: io=25708KB, aggrb=306KB/s, minb=306KB/s, maxb=306KB/s, mint=83860msec, maxt=83860msec
  WRITE: io=25492KB, aggrb=303KB/s, minb=303KB/s, maxb=303KB/s, mint=83860msec, maxt=83860msec
 
Disk stats (read/write):
  sda: ios=6422/5964, merge=0/238, ticks=81457/2073064, in_queue=2173820, util=98.75%

the summery shows the below following things.

Aggrb: Aggregate bandwidth of all the process threads used in the test

Minb: Minimum Bandwidth

Maxb: Maximum bandwidth

Ios: Total input output operation performed with the disks.

in Queue: the total time spend being in queue

util: this shows the percentage of duration in which the disk was kept busy with IO operations during the test. In our example output the util is 98 percent which mens, during the task the disk was kept almost full busy with IO operations.

FIO is a very good tool if you want to test the performance of your disk during the heavy intensice IO operations.

Almost all the tools explained in the above tutorial are very much vast in themselfs. Hope this inroductory tutorial for those tools was helpful for benchmark test.

Rate this article: 
Average: 4 (220 votes)

Comments

hi. This is all good info. thanks for that. Looks like you forgot to put the actual "conv=fdatasync" command in your second example. You mention using fdatasync, but i don't see it there. I was trying to understand exactly how using "fdatasync" is different than not specifiying which option to use with "conv". The file gets created either way, but I suppose using fdatasync actually write it to disk immediately, rather than later?

thanks
bb

slashmaster's picture

Hi b-rad,

I was having some issues ongoing with my <pre> and <code> tags in display while showing source code of linux console on web page..So the issue was this "Due to the strict width of the web page we are currently using, anything beyond that width was stripped off(although present fdatasync part was stripped off in the display.)...I Apologies for that issue..Although the issue is fixed, i still have to edit a lot of our old posts with the newly integrated javascript implementation of showing code in articles.."

Lets get back to fdatasync..So fdatasync and fsync are almost similar, except the fact that fsync issues two write operation requests(One for data another for metadata..modified time etc to the disk.)..fdatasync issues only one write request(only for the data.), so in our case we didnt require metadata, as that is irrelavant as far as speed test is concened.

thanks

Sarath

 

 

 

 

Nicely put & explained. Thank you.

Good work , Thanks for the information

Nice approach.
Thank you for sharing.

Best Information for New Learners about the Performance.

For a noob friendly version of this you can find it at http://vpstip.com/how-to-check-disk-speed-easily-in-linux/

how t run IOs for long time using IOzone

Hello,

I am trying to benchmark the performance of virtual machines through benchmarking the performance of the disk. I am using FIO, and I am wondering what would be a typical file size and block size; I am currently using 2GB, 4GB, 8GB as file sizes, and 4KB, 16KB, 64KB, 512KB as block sizes (knowing that I have a 2GB RAM).

Thanks.

[root@myvm1 sarath]# dd if=speedtest of=/dev/null bs=64k count=24000
5200+0 records in
5200+0 records out
340787200 bytes (341 MB) copied, 3.42937 seconds, 99.4 MB/s

vs

[root@myvm1 ~]# hdparm -tT /dev/sda1

/dev/sda1:
Timing cached reads: 5808 MB in 2.00 seconds = 2908.32 MB/sec
Timing buffered disk reads: 10 MB in 3.12 seconds = 3.21 MB/sec

vs
iozone results above

can u please explain me why there is big difference if we perform read operation with different commands and tools so which result will correctly show you read transfer rate of disk like in this case wether it is 99.4 MB/s or 3.21 MB/sec or the output
which is obtain from iozone, I am confused.

If you run the dd without flushing OS buffers, your file (or a large part of it) might still be in memory and therefore would have been read not from the filesystem but from buffer cache pages. Add some time for metadata handling, and you get something between the two hdparm figures.
Flushing caches is the rationale behind the suggestion to transfer considerably more than your RAM can hold.

BTW: About 100MB/s is quite fast for a spinning disk - a DOM or SSD would be able to keep up with this though.

Thanks. Very helpful information. Thanks for posting it.

Hey , what does it mean if my cached reads are very low. See the below output.

sudo hdparm -tT /dev/sda1

/dev/sda1:
Timing cached reads: 2 MB in 2.85 seconds = 717.83 kB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.98 MB/sec

Does that mean, its the problem with the hard drive or with my CPU and RAM

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.