Pathetic SATA performance

Hi there,

I have a file server, running Etch, with the following specs:

P4, 1.7Ghz
512MB Ram
2 x SI based SATA I controllers
4 x Maxtor 250GB SATA drives

It is set up with software RAID 5, and the overall performance is terrible.

Every time it reboots (which happens due to dodgy power!), it does a RAID
resync, this takes up 90% CPU time (for md0_resync process) for 50 hours!!
During this time, ANY access to the drive is painful.

Now, I expected software RAID 5 to be slow, but not this bad - this is the
reading from hdparm:

bungo:~# hdparm -tT /dev/md0

/dev/md0:
Timing cached reads: 2 MB in 4.71 seconds = 435.05 kB/sec
Timing buffered disk reads: 8 MB in 3.13 seconds = 2.56 MB/sec

Bad eh?

Becuase they're SATA drives, hdparm cannot tune them - or indeed read their
current settings. Is there any way I can speed this beast up, if not I am
going to go back to my old PPro200-based file server, running SCSI->FCAL
bridge.

Cheers,

Pete.

--

0

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Pathetic SATA performance

On Thu, Feb 01, 2007 at 08:34:20PM -0000, Pete Clarke wrote:
> Hi there,
>
> I have a file server, running Etch, with the following specs:
>
> P4, 1.7Ghz
> 512MB Ram
> 2 x SI based SATA I controllers
> 4 x Maxtor 250GB SATA drives
>
> It is set up with software RAID 5, and the overall performance is terrible.
>
> Every time it reboots (which happens due to dodgy power!), it does a RAID
> resync, this takes up 90% CPU time (for md0_resync process) for 50 hours!!
> During this time, ANY access to the drive is painful.
>
> Now, I expected software RAID 5 to be slow, but not this bad - this is the
> reading from hdparm:
>
> bungo:~# hdparm -tT /dev/md0
>
> /dev/md0:
> Timing cached reads: 2 MB in 4.71 seconds = 435.05 kB/sec
> Timing buffered disk reads: 8 MB in 3.13 seconds = 2.56 MB/sec
>
>
> Bad eh?
>
> Becuase they're SATA drives, hdparm cannot tune them - or indeed read their
> current settings. Is there any way I can speed this beast up, if not I am
> going to go back to my old PPro200-based file server, running SCSI->FCAL
> bridge.
>

Wow, that is awful.

I dont' do raid5 since I only have two disks.

Two identical Seagate Barracuda 7200 80 GB SATA drives (with the SATA I
rate limiting jumper removed), on my Asus MB nVidia chipset SATA-II
ports. Each drive has three partitions, to for raid1, one for LVM.

hdparm -tT /dev/md0

/dev/md0
Timing cached reads: 2424 MB in 2.00 seconds = 1212.23 MB/sec
Timing buffered disk reads: 62 MB in 0.84 seconds = 73.44 MB/sec.

What happens if you time the raw drives instead of md0? For me on raid1,
its basically the same. I'm wondering if one or more of your drives are
in difficulty and its slowing down the whole array.

What does smartmontools say about the drive's S.M.A.R.T.s?

Doug.

--

Pathetic SATA performance

> On Thu, Feb 01, 2007 at 08:34:20PM -0000, Pete Clarke wrote:
>> Hi there,
>>
>> I have a file server, running Etch, with the following specs:
>>
>> P4, 1.7Ghz
>> 512MB Ram
>> 2 x SI based SATA I controllers
>> 4 x Maxtor 250GB SATA drives
>>
>> It is set up with software RAID 5, and the overall performance is
>> terrible.
>>
>> Every time it reboots (which happens due to dodgy power!), it does a
>> RAID
>> resync, this takes up 90% CPU time (for md0_resync process) for 50
>> hours!!
>> During this time, ANY access to the drive is painful.
>>
>> Now, I expected software RAID 5 to be slow, but not this bad - this is
>> the
>> reading from hdparm:
>>
>> bungo:~# hdparm -tT /dev/md0
>>
>> /dev/md0:
>> Timing cached reads: 2 MB in 4.71 seconds = 435.05 kB/sec
>> Timing buffered disk reads: 8 MB in 3.13 seconds = 2.56 MB/sec
>>
>>
>> Bad eh?
>>
>> Becuase they're SATA drives, hdparm cannot tune them - or indeed read
>> their
>> current settings. Is there any way I can speed this beast up, if not I
>> am
>> going to go back to my old PPro200-based file server, running SCSI->FCAL
>> bridge.
>>
>
> Wow, that is awful.
>
> I dont' do raid5 since I only have two disks.
>
> Two identical Seagate Barracuda 7200 80 GB SATA drives (with the SATA I
> rate limiting jumper removed), on my Asus MB nVidia chipset SATA-II
> ports. Each drive has three partitions, to for raid1, one for LVM.
>
> hdparm -tT /dev/md0
>
> /dev/md0
> Timing cached reads: 2424 MB in 2.00 seconds = 1212.23 MB/sec
> Timing buffered disk reads: 62 MB in 0.84 seconds = 73.44 MB/sec.
>
> What happens if you time the raw drives instead of md0? For me on raid1,
> its basically the same. I'm wondering if one or more of your drives are
> in difficulty and its slowing down the whole array.
>
> What does smartmontools say about the drive's S.M.A.R.T.s?
>

I get:

bungo:~# smartctl --all /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA ST3250620AS Version: 3.AA
Serial number: 9QE0MLDS
Device type: disk
Local Time is: Thu Feb 1 22:14:32 2007 GMT
Device does not support SMART

Error Counter logging not supported

[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging

As for individual drive performance :

bungo:~# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 322 MB in 2.00 seconds = 160.99 MB/sec
Timing buffered disk reads: 106 MB in 3.00 seconds = 35.29 MB/sec
bungo:~# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads: 348 MB in 2.01 seconds = 173.30 MB/sec
Timing buffered disk reads: 4 MB in 4.62 seconds = 886.44 kB/sec
bungo:~# hdparm -tT /dev/sdc

/dev/sdc:
Timing cached reads: 320 MB in 2.00 seconds = 159.67 MB/sec
Timing buffered disk reads: 36 MB in 5.39 seconds = 6.67 MB/sec
bungo:~# hdparm -tT /dev/sdd

/dev/sdd:
Timing cached reads: 342 MB in 2.01 seconds = 170.41 MB/sec
Timing buffered disk reads: 4 MB in 4.29 seconds = 954.93 kB/sec

Rather poo ...

I *must* be doing something wrong .. I can't believe SATA performance is
*THIS BAD*...

Cheers,

Pete.

--

RE: Pathetic SATA performance

> > What does smartmontools say about the drive's S.M.A.R.T.s?
> >
>
> I get:
>
> bungo:~# smartctl --all /dev/sda
> smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C)
> 2002-6 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
>
> Device: ATA ST3250620AS Version: 3.AA
> Serial number: 9QE0MLDS
> Device type: disk
> Local Time is: Thu Feb 1 22:14:32 2007 GMT
> Device does not support SMART
>
> Error Counter logging not supported
>
> [GLTSD (Global Logging Target Save Disable) set. Enable Save
> with '-S on']
> Device does not support Self Test logging

For SATA, you need to add "-d ata" to the command line, i.e.:

# smartctl -d ata -a /dev/sda

--

Pathetic SATA performance

> For SATA, you need to add "-d ata" to the command line, i.e.:
>
> # smartctl -d ata -a /dev/sda

bungo:~# smartctl -d ata /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

bungo:~# smartctl -d ata /dev/sdb
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

bungo:~# smartctl -d ata /dev/sdc
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

bungo:~# smartctl -d ata /dev/sdd
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Not much info...

--

Pathetic SATA performance

On Fri, Feb 02, 2007 at 07:15:29AM -0000, Pete Clarke wrote:
> >For SATA, you need to add "-d ata" to the command line, i.e.:
> >
> ># smartctl -d ata -a /dev/sda
>
> bungo:~# smartctl -d ata /dev/sda
> smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
>
> Not much info...

So do
smartctl -a -d ata /dev/sda

Doug.

--

RE: Pathetic SATA performance

> -----Original Message-----
> From: Pete Clarke [mailto:pete@devilincarnate.eclipse.co.uk]
> Sent: Thursday, February 01, 2007 11:15 PM
> To:
> Subject: Re: Pathetic SATA performance
>
> > For SATA, you need to add "-d ata" to the command line, i.e.:
> >
> > # smartctl -d ata -a /dev/sda
>
> bungo:~# smartctl -d ata /dev/sda
> smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C)
> 2002-6 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
>
> Not much info...

You forgot the "-a".

-- Kevin

--

Pathetic SATA performance

On 2007-02-01 20:34 -0000, Pete Clarke wrote:

> I have a file server, running Etch, with the following specs:
>
> P4, 1.7Ghz
> 512MB Ram
> 2 x SI based SATA I controllers
> 4 x Maxtor 250GB SATA drives
>
> It is set up with software RAID 5, and the overall performance
> is terrible.
>
> bungo:~# hdparm -tT /dev/md0
>
> /dev/md0:
> Timing cached reads: 2 MB in 4.71 seconds = 435.05 kB/sec
> Timing buffered disk reads: 8 MB in 3.13 seconds = 2.56 MB/sec

There was/is an issue with certain Maxtor SATA hard disk drives.
In some cases, it is necessary to force them to SATA-I mode (1.5
gb/s). There's a jumper in the back for that.

> 4 x Maxtor 250GB SATA drives

(Incidentally I would recommend against making a RAID array from
several drives from the same manufacturer. Especially if they're
the same model. Even more so if they're the same batch.)

--
André Majorel
Discriminating spammers prefer bugs.debian.org.

--

Pathetic SATA performance

> There was/is an issue with certain Maxtor SATA hard disk drives.
> In some cases, it is necessary to force them to SATA-I mode (1.5
> gb/s). There's a jumper in the back for that.

Yep, set that :-)

>> 4 x Maxtor 250GB SATA drives
>
> (Incidentally I would recommend against making a RAID array from
> several drives from the same manufacturer. Especially if they're
> the same model. Even more so if they're the same batch.)

Why so?

--

Pathetic SATA performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/07 01:14, Pete Clarke wrote:
[snip]
>>> 4 x Maxtor 250GB SATA drives
>>
>> (Incidentally I would recommend against making a RAID array from
>> several drives from the same manufacturer. Especially if they're
>> the same model. Even more so if they're the same batch.)
>
> Why so?

Defects tend to happen to all the units in a certain production run.
If one goes, the others may go before you can replace & rebuild the
first bad drive.

I'd still prefer to have all my RAID drives be the same manufacturer
+ model. Maybe that's just an ingrained habit I picked up in the
1990s.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFwuZQS9HxQb37XmcRAjp7AKDiJH5LbCw0Hhd0TEbBxG4HGxI2TwCcDRjI
bJ/psh8oL1ZapkiA9LR0MyY=
=40oo
-----END PGP SIGNATURE-----

--

Pathetic SATA performance

> Defects tend to happen to all the units in a certain production run.
> If one goes, the others may go before you can replace & rebuild the
> first bad drive.

Fair enough.

> I'd still prefer to have all my RAID drives be the same manufacturer
> + model. Maybe that's just an ingrained habit I picked up in the
> 1990s.

Indeed ... I thought it would be better to have all the same, as I remember
different brands of drive sometimes had incompatibilities (WD and Maxtor
spring to mind).
Also, as it defaults to the smallest size, having all drives the same means
you don't lose any more space than the parity drive.

Cheers

--

Pathetic SATA performance

On 2007-02-02 07:56 -0000, Pete Clarke wrote:

> >I'd still prefer to have all my RAID drives be the same manufacturer
> >+ model. Maybe that's just an ingrained habit I picked up in the
> >1990s.
>
> Indeed ... I thought it would be better to have all the same, as
> I remember different brands of drive sometimes had
> incompatibilities (WD and Maxtor spring to mind).

I don't think that would be an issue with SATA since there is no
shared bus.

> Also, as it defaults to the smallest size, having all drives the
> same means you don't lose any more space than the parity drive.

Disk sizes are rather uniform these days. As far as I can tell
IBM/Hitachi, Samsung, Seagate and Western Digital have the same
size (200 GB = 24321 cylinders, 250 GB = 30401 cylinders, 500 GB =
60801 cylinders). The only exception is Maxtor which is always a
little bigger (250 GB = 30515 cylinders).

--
André Majorel
bugs.debian.org, food for your spambots.

--

Pathetic SATA performance

On 2007-02-02 07:14 -0000, Pete Clarke wrote:

> >There was/is an issue with certain Maxtor SATA hard disk drives.
> >In some cases, it is necessary to force them to SATA-I mode (1.5
> >gb/s). There's a jumper in the back for that.
>
> Yep, set that :-)

You mean that was not the issue ? You have a problem then. I'd
disconnect all the drives but one and see if I can isolate a
culprit.

SATA should not be as suceptible as IDE to one device taking down
the whole interface but still, I've had a SATA Hitachi freeze the
whole system, so it's worth trying...

--
André Majorel
Choosy spammers prefer bugs.debian.org.

--

Pathetic SATA performance

> You mean that was not the issue ? You have a problem then. I'd
> disconnect all the drives but one and see if I can isolate a
> culprit.

Yep, set the SATA I jumper before setting the drives up.

> SATA should not be as suceptible as IDE to one device taking down
> the whole interface but still, I've had a SATA Hitachi freeze the
> whole system, so it's worth trying...

Trouble is, the drives are set up as a RAID 5 array - if I disconnect them
one by one I will lose data?

--

Pathetic SATA performance

On 2007-02-02 09:25 -0000, Pete Clarke wrote:

> > You mean that was not the issue ? You have a problem then. I'd
> > disconnect all the drives but one and see if I can isolate a
> > culprit.
>
> Yep, set the SATA I jumper before setting the drives up.

Ah. Sorry.

> > SATA should not be as suceptible as IDE to one device taking down
> > the whole interface but still, I've had a SATA Hitachi freeze the
> > whole system, so it's worth trying...
>
> Trouble is, the drives are set up as a RAID 5 array - if I
> disconnect them one by one I will lose data?

No need to mount the filesystems or even assemble the arrays. Just
run hdparm -t on the drive, power off, disconnect the drive,
connect the next drive, power on...

--
André Majorel
Discriminating spammers prefer bugs.debian.org.

--

Pathetic SATA performance

On Fri, Feb 02, 2007 at 01:33:15PM -0000, Pete Clarke wrote:
> > So do
> > smartctl -a -d ata /dev/sda
>
> Doh ...
> :-)
>
> Everything looks OK from a SMART point of view:
>
> bungo:~# smartctl -d ata -a /dev/sda
> SMART Error Log Version: 1
> No Errors Logged
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing

> bungo:~# smartctl -d ata -a /dev/sdb
> SMART Error Log Version: 1
> No Errors Logged
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
> Selective self-test flags (0x0):

> bungo:~# smartctl -d ata -a /dev/sdc
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing

> bungo:~# smartctl -d ata -a /dev/sdd
> SMART Error Log Version: 1
> No Errors Logged
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
> Selective self-test flags (0x0):

Except that no self-tests have ever been done on the drives.
Try a -t long.

Doug.

--

Syndicate content