# SATA drives slow

## Schizoid

I am using the ATA_PIIX kernel driver for my SATA controller. There are two new, identical 500gb SATA hard disk and a single SATA dvd-rw drive in the system.

This computer is less than two months old and it never seems to perform well when it comes to file operations. For example. I had a backup of my /usr/portage directory which today I finally got around to removing with an rm -r /usr/portage.old command. This is less than 250mb, and it took well over 10 minutes to complete the operation. I washed out my tea pot, boiled some water, and steeped a fresh cup of tea and it still had not finished. I realize there are a zillion small files in there, but come on!

I have been using dd to copy some dvds to one of the partitions, using a simple dd if=/dev/dvd of=image.iso command. dd is kind enough to let me know that this operation is performing at around 11mb/sec. That is around 8x for a dvd drive. Should it not be a lot faster than this? (Using an ext3 partition instead of XFS gets me 12.5mb/sec)

The computer is always very responsive, but waiting over ten minutes to delete 250mb is a joke. There has to be something off here, right?! I thought it might be XFS so I put ext3 on a partition and as you can see above things are not really much better.

----------

## likewhoa

you might want to consider putting those two drives in a RAID array for performance increases, you might also want to switch to a different iosched and or play with 

```
blockdev --setra VALUE /dev/DRIVE
```

----------

## Schizoid

First off I just want to point out that the 12.5mb/sec number was an XFS partition, and the 11mb/sec is for the ext3. I had them mixed up.

I set blockdev --setra 16384 on both disks and the dvdr (all were at 256 previously) and when using the same dd command that gets me 14.7mb/sec on the ext3 (from 11mb/sec). For the XFS partition I get 15.4mb/sec.

Copying the file from the XFS partition to the ext3 (on separate physical disks) I get a rate of about 25.2mb/sec (4465mb in 177 seconds).

These don't seem like the best numbers to me. Do you think the file systems are a factor here? I don't know what else to try to adjust when it comes to SATA.

Thanks for the help.

Oh, and I am using the default cfq scheduler. This system has a quad-core cpu and 2gb of ram. I have never setup a raid array and I don't really want to fiddle with that if I don't have to. If the drives don't seem to be performing well without being in an array the array will just help to mask their poor performance, eh?

----------

## likewhoa

 *Schizoid wrote:*   

> First off I just want to point out that the 12.5mb/sec number was an XFS partition, and the 11mb/sec is for the ext3. I had them mixed up.
> 
> I set blockdev --setra 16384 on both disks and the dvdr (all were at 256 previously) and when using the same dd command that gets me 14.7mb/sec on the ext3 (from 11mb/sec). For the XFS partition I get 15.4mb/sec.
> 
> Copying the file from the XFS partition to the ext3 (on separate physical disks) I get a rate of about 25.2mb/sec (4465mb in 177 seconds).
> ...

 

try with the deadline scheduler. the average transfer rate should be about 40MB/s and up. 12MB/s just seems slow to me. you might also want to test from a livecd to rule out the kernel.

----------

## Schizoid

I will give that a shot next time I rebuild the kernel.

Am I crazy or isn't there a way to change scheduler without rebooting?

----------

## gimpel

 *Schizoid wrote:*   

> I will give that a shot next time I rebuild the kernel.
> 
> Am I crazy or isn't there a way to change scheduler without rebooting?

 

```
$ cat /sys/block/sda/queue/scheduler 

noop anticipatory deadline [cfq]

$ echo deadline > /sys/block/sda/queue/scheduler
```

 :Wink: 

----------

## niceness

 *Schizoid wrote:*   

> Am I crazy or isn't there a way to change scheduler without rebooting?

 

```
# cat /sys/block/sda/queue/scheduler

noop [anticipatory] deadline cfq

# echo deadline > /sys/block/sda/queue/scheduler

# cat /sys/block/sda/queue/scheduler

noop anticipatory [deadline] cfq
```

EDIT:

@gimpel

2 minutes faster...

----------

## mbar

 *Schizoid wrote:*   

> I am using the ATA_PIIX kernel driver for my SATA controller.

 

If your mainboard has ICH9/ICH9R chipset you should choose AHCI mode in BIOS for Linux installation. I'm getting close to 76 MB/s physical transfer speed between two identical WD 500 GB drives.

----------

## Schizoid

 *mbar wrote:*   

>  *Schizoid wrote:*   I am using the ATA_PIIX kernel driver for my SATA controller. 
> 
> If your mainboard has ICH9/ICH9R chipset you should choose AHCI mode in BIOS for Linux installation. I'm getting close to 76 MB/s physical transfer speed between two identical WD 500 GB drives.

 

Yes, it is an Asus P5K board. I have seen people suggest AHCI mode before but there is nothing in the bios to adjust. The only SATA setting in there is an option to choose between "Normal" mode and a "compatibility" mode. It does not make clear what these do. I have tried both and they don't seem to make any difference.

Is there a way to see if AHCI mode is on or working?

With the deadline scheduler I get 15.3mb/sec doing a dd from the dvdrom to an ext3 partition, and 15.4mb/sec going to an XFS partition. Copying the file from one partition to the other is the same 25mb/sec rate.

----------

## Schizoid

As another example, unpacking source files always takes a very long time. I feel like the computer can compile things faster than it can unpack the source code sometimes.

```

patrick@Gohan ~ $ time tar jxf firefox-3.0b1-source.tar.bz2 

real    3m5.543s

user    0m12.254s

sys     0m2.369s

patrick@Gohan ~ $ ls -oa firefox-3.0b1-source.tar.bz2 

-rw-r--r-- 1 patrick 34385058 2007-11-22 03:20 firefox-3.0b1-source.tar.bz2

patrick@Gohan ~ $

```

Granted, there are lots of tiny files in source code, but my old clunker with an ata4 ide drive was faster than this.

----------

## Lifthanger

I have the same problem on my amd64 gentoo. My root is XFS and esspecially untaring sources and deleting them again takes a very long time. Monitoring the process with dstat showed write speeds of under 10MB/s while hdparm -t gives around 95 MB/s.

Maybe we can find a solution together.

----------

## Schizoid

Ugh, here is the same operation on an ext3 partition in the same system.

```

patrick@Gohan /mnt/Local $ time tar jxf firefox-3.0b1-source.tar.bz2 

real    0m24.867s

user    0m10.606s

sys     0m1.884s

```

A bit of an improvement, eh?

----------

## Lifthanger

hmm seems like an xfs issue..

I'll install another hdd to make some test partitions today. I'll post the results.

----------

## Lifthanger

the results: untaring the 55MB netbeans sources and rm -rf of the sources afterwards. Kernel is 2.6.23 AMD64 - io-scheduler doesn't make a difference.

The HDD yields 75MB/s in hdparm.

reiserfs3:

real    0m31.201s

user    0m26.055s

sys     0m3.274s

real    0m2.791s

user    0m0.052s

sys     0m2.548s

ext2:

real    0m30.638s

user    0m25.794s

sys     0m2.300s

real    0m0.866s

user    0m0.032s

sys     0m0.416s

xfs:

real    3m37.179s

user    0m26.066s

sys     0m4.524s

real    2m27.426s

user    0m0.052s

sys     0m2.080s

This last test is on a software raid 5 array with 32bit kernel. hdparm nets around 140MB/s but on heavy access it gets cpu restricted, or at least that was my impression.

xfs:

real    1m47.089s

user    0m48.151s

sys     0m7.888s

real    0m21.938s

user    0m0.184s

sys     0m4.876s

Seems to me as if xfs and AMD64 don't like each other very much... I'm open to other conclusions though.

----------

## nbkolchin

Try this guide for XFS tuning: http://www.everything2.com/index.pl?node_id=1479435

----------

