Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Solid State Drives?

19 views
Skip to first unread message

root

unread,
Jan 7, 2012, 2:08:00 PM1/7/12
to

Are the solid state drives which are rated sata-600
any faster than spinning hard disks equivalently
rated?

hdparm rates my spinning disk:
/dev/sda:
Timing cached reads: 23882 MB in 1.99 seconds = 11975.70 MB/sec
Timing buffered disk reads: 438 MB in 3.01 seconds = 145.35 MB/sec

The "advertised" speed of a Corsair 240Gb drive is 550/520 Mb/sec
which is 3.5 times as fast.

Any experience with these drives?

Thanks.

unruh

unread,
Jan 7, 2012, 3:09:23 PM1/7/12
to
On 2012-01-07, root <NoE...@home.org> wrote:
>
> Are the solid state drives which are rated sata-600
> any faster than spinning hard disks equivalently
> rated?
>
> hdparm rates my spinning disk:
> /dev/sda:
> Timing cached reads: 23882 MB in 1.99 seconds = 11975.70 MB/sec
> Timing buffered disk reads: 438 MB in 3.01 seconds = 145.35 MB/sec
>
> The "advertised" speed of a Corsair 240Gb drive is 550/520 Mb/sec
> which is 3.5 times as fast.

I persume you meant 240GB.

No, that is about 3 times as slow. Mb/s is Mega bits per second while
MB/sec is MegaBytes per second, and a byte is 8 bits.

root

unread,
Jan 7, 2012, 6:24:58 PM1/7/12
to
I'm sorry, I was careless in the use of B/b. I should have
used B throughout.

I went out and bought the 240GB Corsair drive. I installed it
as sda1 and moved my previous sda to sdb. Now here is what
hdparm says:
/dev/sda:
Timing cached reads: 25034 MB in 1.99 seconds = 12555.29 MB/sec
Timing buffered disk reads: 956 MB in 3.00 seconds = 318.33 MB/sec
aa:/root>hdparm -Tt /dev/sdb

/dev/sdb:
Timing cached reads: 24722 MB in 1.99 seconds = 12398.53 MB/sec
Timing buffered disk reads: 482 MB in 3.02 seconds = 159.77 MB/sec
aa:/root>hdparm -Tt /dev/sdc

/dev/sdc:
Timing cached reads: 24376 MB in 1.99 seconds = 12224.45 MB/sec
Timing buffered disk reads: 412 MB in 3.00 seconds = 137.29 MB/sec

I ran a check while I was copying over my installation to the
new drive, and then the speed was given as 475MB/s. Now it is
a mere twice as fast as the spinning drive. My sdc is a SATA2
drive.

Martin

unread,
Jan 8, 2012, 6:13:15 PM1/8/12
to
not with this drive specifically. In certain "seeky" access scenarios the
SSD's advantage is much more significant, but there is a reason that most of
the reports feeding the SSD hype include

(a) Ms Windows
(b) initial access scenarios (like booting or firing up an application for
the first time)

I switched my linux systems to SSD and yes I enjoy faster boot times and
faster loading of apps, but on the whole the difference is underwhelming.

Martin

root

unread,
Jan 8, 2012, 10:50:28 PM1/8/12
to
Maybe you can explain something strange that I observed. I was running
a SATA3 hard drive as sda. I plugged the SSD into the second slot
on my MB so it would come up as sdb. Before I copied the contents
of sda over to the new drive I did hdparm Tt /dev/sdb
and it came up with something like 12500MB/s cached and 475MB/sec
direct. I was pretty happy: the direct speed of the new drive was
about 3 times as fast as my spinning drive.

I partitioned the 240GB into 2 120GB partitions, created an ext4
fs on sdb1 and copied the contents of sda1 over to sdb1.

I powered down, swapped the two sata cables, and booted up
with my slackware install disk, directing the kernel to
go to /dev/sda1. I had to do this because there was no
boot sector on sda. I then ran lilo and am thereafter
able to boot into the SSD.

Once booted into the new system I ran a new hdparm
and this time the direct speed was only 318MB/s.
Something happened that cut the speed by 1/3.

I tried swapping cables, taking the spinning drives
out of the system, whatever. Always now the speed is
slower than when the SSD came out of the box.

Any ideas of what might have happened?

Thanks.

bad sector

unread,
Jan 8, 2012, 11:23:05 PM1/8/12
to
Just a wide and wild guess, did you use the new (allegedly ssd oriented)
version of fdisk or whichever (ssd alignement etc.)?

Other than that, I tried a borrowed ssd last month and gave it back
within the hour (not running a server). Might try another one in a few
years when they are cheaper than real drives :-(

root

unread,
Jan 8, 2012, 11:50:18 PM1/8/12
to
bad sector <none@_INVALID_.net> wrote:
> Just a wide and wild guess, did you use the new (allegedly ssd oriented)
> version of fdisk or whichever (ssd alignement etc.)?

I just used the fdisk which came with Slackware 13.37: version 2.19 I think.

bad sector

unread,
Jan 9, 2012, 12:28:52 AM1/9/12
to
On 01/08/2012 11:50 PM, root wrote:
> bad sector<none@_INVALID_.net> wrote:
>> Just a wide and wild guess, did you use the new (allegedly ssd oriented)
>> version of fdisk or whichever (ssd alignement etc.)?
>
> I just used the fdisk which came with Slackware 13.37: version 2.19 I think.

if the first sector created is 2048 by default then it's probably the
new version which should be ok. I installed 13.37 but didn't use the
fdisk that bundled with it.

Here's some more, maybe out of date now

http://www.ocztechnologyforum.com/forum/showthread.php?77769-A-Simple-How-To-on-Partitioning-and-Alignment-on-GNU-Linux-using-fdisk


I kept an old version of fdisk just for those times when I want to start
with sector 63 instead (I'm not using any ssd's).

hth


Pascal Hambourg

unread,
Jan 9, 2012, 3:38:40 AM1/9/12
to
Hello,

root a écrit :
>
> Maybe you can explain something strange that I observed. I was running
> a SATA3 hard drive as sda. I plugged the SSD into the second slot
> on my MB so it would come up as sdb. Before I copied the contents
> of sda over to the new drive I did hdparm Tt /dev/sdb
> and it came up with something like 12500MB/s cached and 475MB/sec
> direct. I was pretty happy: the direct speed of the new drive was
> about 3 times as fast as my spinning drive.
>
> I partitioned the 240GB into 2 120GB partitions, created an ext4
> fs on sdb1 and copied the contents of sda1 over to sdb1.
[...]
> Once booted into the new system I ran a new hdparm
> and this time the direct speed was only 318MB/s.
> Something happened that cut the speed by 1/3.
[...]
> Any ideas of what might have happened?

Just another wild guess : is is possible that the disk controller knows
that a block does not contain data (because it has never been written,
or has been erased with TRIM) and does not actually read the data from
it, a bit like when reading a sparse file ?

I do not think partition alignment has an effect on the raw speed.

root

unread,
Jan 9, 2012, 10:54:20 AM1/9/12
to
Thanks for the response. My first sector does start at 2048.

Martin

unread,
Jan 9, 2012, 3:21:03 PM1/9/12
to
root wrote:

> Maybe you can explain something strange that I observed. I was running
> a SATA3 hard drive as sda. I plugged the SSD into the second slot
> on my MB so it would come up as sdb. Before I copied the contents
> of sda over to the new drive I did hdparm Tt /dev/sdb
> and it came up with something like 12500MB/s cached and 475MB/sec
> direct. I was pretty happy: the direct speed of the new drive was
> about 3 times as fast as my spinning drive.
>
> I partitioned the 240GB into 2 120GB partitions, created an ext4
> fs on sdb1 and copied the contents of sda1 over to sdb1.
>
> I powered down, swapped the two sata cables, and booted up
> with my slackware install disk, directing the kernel to
> go to /dev/sda1. I had to do this because there was no
> boot sector on sda. I then ran lilo and am thereafter
> able to boot into the SSD.
>
> Once booted into the new system I ran a new hdparm
> and this time the direct speed was only 318MB/s.
> Something happened that cut the speed by 1/3.
>
> I tried swapping cables, taking the spinning drives
> out of the system, whatever. Always now the speed is
> slower than when the SSD came out of the box.
>
> Any ideas of what might have happened?
>
> Thanks.

unfortunately not, given that hdparm -tT is purely a read benchmark. If it
did write I would speculate on ATA TRIM and wear levelling, but I wouldn't
expect a degradation of reads (unless Pascal is on to something in the
parallel post).

You can try using Mark Lord's script wiper.sh (available on hdparm's project
page on sourceforge) to declare unused space to the SSD controller and see
if that makes a difference. You need to unmount the SSD partitions for that.

Oh, and you do mount your ext4 partitions with the options discard, noatime,
nodiratime, don't you? And all temporary directories are in RAM?

Martin

root

unread,
Jan 9, 2012, 7:39:54 PM1/9/12
to
Martin <n...@spam.invalid> wrote:
>
> Oh, and you do mount your ext4 partitions with the options discard, noatime,
> nodiratime, don't you? And all temporary directories are in RAM?
>
> Martin
>

Thanks, I will play around with that. I just mounted it
with a standard entry in fstab.

Mark F

unread,
Jan 12, 2012, 12:39:56 PM1/12/12
to
I find things only somewhat faster with Windows 7 64-bit and OCZ
Technology Vertex 3 MAXIOPS compared to Western Digital WDC
WD3000GLFS-01F8U using only the outer half of the spinning drive to
speed it up.

However, I have some programs that have 20000 to 200000 or more files
in a single directory. These programs were not useable with 40000
files in a directory using the outside 1/10th of a Seagate
Constellation ES ST32000NM001 drive, but have no problems running with
250000 or more files on a OCZ Vertex 3 MAXIOPS. (Again, this is under
Windows 7 using NTFS, so it is possible that EXT4 behaves well enough
so that you wouldn't see a difference between spinning and
non-spinning drives.)

>
> Martin

Martin

unread,
Jan 12, 2012, 3:36:01 PM1/12/12
to
Mark F wrote:

> However, I have some programs that have 20000 to 200000 or more files
> in a single directory. These programs were not useable with 40000
> files in a directory using the outside 1/10th of a Seagate
> Constellation ES ST32000NM001 drive, but have no problems running with
> 250000 or more files on a OCZ Vertex 3 MAXIOPS. (Again, this is under
> Windows 7 using NTFS, so it is possible that EXT4 behaves well enough
> so that you wouldn't see a difference between spinning and
> non-spinning drives.)

i know from experience, when traversing a directory with many files for the
first time it takes a while under ext4. However, when traversing it a second
time everything should be served from the block buffer, so any speed
difference between devices should be gone.

Martin

0 new messages