# Hard drive performance



## xy16644 (Jul 21, 2012)

How do I ensure that the disks in my FreeBSD server are running at the optimal speed? I have two 160GB SATA II drives in my server and I wanted to make sure they were running at the maximum possible speed.

The output from my /var/run/dmesg.boot is as follows:

```
ad4: 152587MB <SAMSUNG HD160JJ/P ZM100-34> at ata2-master UDMA100 SATA
ad6: 152627MB <WDC WD1600BLHX-60V7BV0 04.05G04> at ata3-master UDMA100 SATA
```

When I do a dump to disk I get about 9 megabytes per second which seems slow? Is there anything I can or should do to improve the performance of my disks? Do I need to tweak anything?

I'm running FreeBSD 9.0-RELEASE-p3 i386.

Thanks for any help! :e


----------



## wblock@ (Jul 21, 2012)

There are a lot of variables.  diskinfo(8)'s -t option will give an idea of maximum speeds:
`% diskinfo -tv /dev/ad4`

That's best-case, and most real usage will not get near that speed.  Other things that will affect disk speed are drivers (using AHCI, if available, can give 5-20% speed improvement), 4K block alignment on newer drives, buffer sizes (-b and -C for dump(8)), disk head contention (dumping one filesystem to a file elsewhere on the same disk), and other I/O bottlenecks (dumping over Ethernet).


----------



## xy16644 (Jul 21, 2012)

Thanks for mentioning that command, very useful. I currently have two 160GB drives mirrored in my machine. Ones a Samsung 7200RPM SATA drive which gets the following transfer rates from: [CMD="*"]diskinfo -tv /dev/ad4[/CMD]

```
Transfer rates:
        outside:       102400 kbytes in   1.699766 sec =    60244 kbytes/sec
        middle:        102400 kbytes in   2.050189 sec =    49947 kbytes/sec
        inside:        102400 kbytes in   3.238156 sec =    31623 kbytes/sec
```

The other drive is an Enterprise Western Digital 10000RPM 160GB SATA drive. This gets the following transfer rates:

```
Transfer rates:
        outside:       102400 kbytes in   0.849378 sec =   120559 kbytes/sec
        middle:        102400 kbytes in   0.892102 sec =   114785 kbytes/sec
        inside:        102400 kbytes in   0.976681 sec =   104845 kbytes/sec
```

Is it possible to have the (much) faster drive in the mirror be the "primary" disk?


----------



## wblock@ (Jul 21, 2012)

Depending on the balancing algorithm chosen when the mirror was created, the faster drive may already be the preferred drive.  See the values for the -b option in gmirror(8).  But these might only affect reads, not writes: data from a mirror can be read from any drive, but writes have to go to all drives.


----------



## xy16644 (Jul 21, 2012)

My mirror was created with the defaults so it looks like its using the "load" option. I changed this to prefer as follows:
[CMD="*"]gmirror configure -b prefer RootMirror0[/CMD]

If I do an [CMD="*"]gmirror list[/CMD]  the balance option says its "prefer" now.

I'm having difficulty changing the priority though. I have tried:

```
gmirror configure -p 1 MirrorDisk1
```

but it says:

```
gmirror: Priority needs a disk name
```


----------



## xy16644 (Jul 21, 2012)

Think I have it:

```
gmirror configure -p 2 RootMirror0 label/MirrorDisk0
```

So label/MirrorDisk0 has priority 2 and label/MirrorDisk1 has priority 1. 

Have I done this correctly? I assume the lower the priority number the higher the priority is (if that makes sense!)?


----------



## wblock@ (Jul 21, 2012)

gmirror(8) says the "biggest" priority wins.  I've never messed with priorities.  load ought to accomplish the same thing.  Benchmarking is the way to be sure.  Changes in write speed won't be visible with diskinfo(8)'s read-only test.  benchmarks/bonnie++ will give a more realistic result for both read and write, but takes longer and can be tricky to do right.


----------



## xy16644 (Jul 21, 2012)

Thanks for that. Is there a way to find out what your labeled disk maps to physically? In other words...how do I find out what the physical drive model/brand is for [CMD=""]label/MirrorDisk0[/CMD]


----------



## wblock@ (Jul 21, 2012)

diskinfo(8) will do it:

```
% diskinfo -v /dev/label/MirrorDisk0
/dev/label/MirrorDisk0
	512         	# sectorsize
	32768       	# mediasize in bytes (32k)
	64          	# mediasize in sectors
	0           	# stripesize
	17408       	# stripeoffset
	0           	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	[color="Red"]WD-WCAW12345678[/color]	# Disk ident.
```


----------



## xy16644 (Jul 21, 2012)

Aah, thank you very much! Once I have changed the balancing algorithm and the disks priorities...are the changes immediate? Or is a reboot needed?


----------



## wblock@ (Jul 21, 2012)

xy16644 said:
			
		

> Aah, thank you very much! Once I have changed the balancing algorithm and the disks priorities...are the changes immediate? Or is a reboot needed?



No idea, but it wouldn't hurt.


----------



## xy16644 (Jul 21, 2012)

Thanks for all your help!


----------



## xy16644 (Jul 21, 2012)

Interestingly, here is my output (since making the changes) from:

[CMD=""]diskinfo -tv /dev/mirror/RootMirror0[/CMD]


```
/dev/mirror/RootMirror0
        512             # sectorsize
        159999998976    # mediasize in bytes (149G)
        312499998       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset

Seek times:
        Full stroke:      250 iter in   2.304794 sec =    9.219 msec
        Half stroke:      250 iter in   1.907077 sec =    7.628 msec
        Quarter stroke:   500 iter in   3.332844 sec =    6.666 msec
        Short forward:    400 iter in   2.143446 sec =    5.359 msec
        Short backward:   400 iter in   0.837849 sec =    2.095 msec
        Seq outer:       2048 iter in   0.265465 sec =    0.130 msec
        Seq inner:       2048 iter in   0.279073 sec =    0.136 msec
Transfer rates:
        outside:       102400 kbytes in   0.856780 sec =   119517 kbytes/sec
        middle:        102400 kbytes in   0.901269 sec =   113618 kbytes/sec
        inside:        102400 kbytes in   0.979617 sec =   104531 kbytes/sec
```

Getting really good transfer rates which means its using the faster disk as the "primary"...brilliant!


----------



## wblock@ (Jul 21, 2012)

Does the dump go any faster?  When testing, use the same parameters.  After that, be sure to use -b64.  It can make dumps nearly twice as fast as the default.


----------



## xy16644 (Jul 21, 2012)

Well I'm glad you asked :e

I did a backup this morning using the following dump command:
[CMD=""]dump -0uaLf /tmp/alpha.dump /dev/ufs/MirrorRootFS[/CMD]

This took about 30 minutes.

After making the changes discussed in this thread AND changing the dump command to:
[CMD=""]dump -b64 -0uaLf /tmp/alpha.dump /dev/ufs/MirrorRootFS[/CMD]

it took about 11 minutes!! Throughput is much better. It was about 8 megabytes per second this morning and its now 17 megabytes per second!!

Thanks for the awesome tips, they've made a HUGE difference!! :e


----------



## wblock@ (Jul 21, 2012)

Without testing separately, there's no way to tell which change made the difference.  I'd guess it was mostly the -b64.


----------

