Linux RAID subsystem development
 help / color / mirror / Atom feed
* raid1 - ssd, doubts
@ 2014-09-30 14:50 Roberto Spadim
  2014-09-30 15:46 ` Andrei Banu
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Roberto Spadim @ 2014-09-30 14:50 UTC (permalink / raw)
  To: Linux-RAID

hi guys!
i will use a ssd raid1, i want know if raid1 trim is supported at mdadm
i will use a 840 evo (or evo pro not selected the right one yet) 500gb
each, raid1, today database size is 100gb, i think it will grow
10gb/year, i had many space...

the point are: madm raid1 trim is supported? or should i use lvm?
should i partition it with 400gb and leave 100gb untouched? or should
i use a hdd+ssd and dmcache?


:) thanks guys, that's a small enterprise solution, they can't buy
raid cards and sas harddisk are same price of ssd :)

any idea/experience and information is wellcome


-- 
Roberto Spadim

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 14:50 raid1 - ssd, doubts Roberto Spadim
@ 2014-09-30 15:46 ` Andrei Banu
  2014-09-30 16:20   ` Roberto Spadim
  2014-10-01  0:36 ` Brassow Jonathan
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Andrei Banu @ 2014-09-30 15:46 UTC (permalink / raw)
  To: Roberto Spadim, Linux-RAID

Hi,

I am in no way of the same technical caliber as many of the people on this
list so please take my advice with a grain of salt. However I do have some
experience with Samsung SSDs in RAID 1 software (md-raid) and I would like
to warn you against it.

My setup is with 840 PROs of 512GB. I did leave free space (not partitioned)
for OP. The SSDs are connected on SATA3.

I'll give you the result of 2 tests and if you are happy, go ahead:

READ
root [~]# hdparm -t /dev/sda
/dev/sda:
  Timing buffered disk reads: 292 MB in  3.01 seconds =  96.92 MB/sec

WRITE
root [~]# dd if=/dev/zero of=testn bs=4k count=256k conv=fdatasync
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 13.4047 s, 80.1 MB/s

When the setup is fresh you'll get significantly more out of it but 
after a while
(this setup is roughly 1 year old) this is what you get with Samsung SSDs in
RAID1 SW. At least this is my experience and I did try to improve it. As 
a matter
of fact, before making a secure erase of one of the SSDs the write speed 
was
under 10MB/s. What you see above is a lot better than what it started out
(but it's true that after the secure erase the read/write speeds were a lot
better but it dropped in a very short time frame).

A few points:
1. CAUTION: 840 EVO are proved to have a read speed degradation for old
data written to the drive (this is unrelated to RAID but it probably 
affects
performance in RAID).
2. I believe that any SSDs, regardless of the brand, in a software 
RAID-1 setup
might be a bad idea.
3. I believe that the same SSDs in a hardware RAID setup might lead to a
different story.

Again: I am not a technical wiz (like many of the people on this list) 
but I did
have some experience with this so I thought I should let you know.

Kind regards!



On 30.09.2014 17:50, Roberto Spadim wrote:
> hi guys!
> i will use a ssd raid1, i want know if raid1 trim is supported at mdadm
> i will use a 840 evo (or evo pro not selected the right one yet) 500gb
> each, raid1, today database size is 100gb, i think it will grow
> 10gb/year, i had many space...
>
> the point are: madm raid1 trim is supported? or should i use lvm?
> should i partition it with 400gb and leave 100gb untouched? or should
> i use a hdd+ssd and dmcache?
>
>
> :) thanks guys, that's a small enterprise solution, they can't buy
> raid cards and sas harddisk are same price of ssd :)
>
> any idea/experience and information is wellcome
>
>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 15:46 ` Andrei Banu
@ 2014-09-30 16:20   ` Roberto Spadim
  2014-09-30 19:58     ` Robert L Mathews
  0 siblings, 1 reply; 9+ messages in thread
From: Roberto Spadim @ 2014-09-30 16:20 UTC (permalink / raw)
  To: Andrei Banu; +Cc: Linux-RAID

nice :) well today it use hdd with sata, 500GB with raid 1 (2 disks)
the only problem is the disk being old, i must replace it
i'm considering ssd only by the price and myth, hdd works well today
i have some doubts about performace without the raid card as you told,
the last ssd i used was enterprise level not desktop/non enterprise
level, and with a raid card

well, others experiences and comments are wellcome :)
comments about cache (bcache,flashcache,dm cache) are wellcome too


2014-09-30 12:46 GMT-03:00 Andrei Banu <andrei.banu@redhost.ro>:
> Hi,
>
> I am in no way of the same technical caliber as many of the people on this
> list so please take my advice with a grain of salt. However I do have some
> experience with Samsung SSDs in RAID 1 software (md-raid) and I would like
> to warn you against it.
>
> My setup is with 840 PROs of 512GB. I did leave free space (not partitioned)
> for OP. The SSDs are connected on SATA3.
>
> I'll give you the result of 2 tests and if you are happy, go ahead:
>
> READ
> root [~]# hdparm -t /dev/sda
> /dev/sda:
>  Timing buffered disk reads: 292 MB in  3.01 seconds =  96.92 MB/sec
>
> WRITE
> root [~]# dd if=/dev/zero of=testn bs=4k count=256k conv=fdatasync
> 262144+0 records in
> 262144+0 records out
> 1073741824 bytes (1.1 GB) copied, 13.4047 s, 80.1 MB/s
>
> When the setup is fresh you'll get significantly more out of it but after a
> while
> (this setup is roughly 1 year old) this is what you get with Samsung SSDs in
> RAID1 SW. At least this is my experience and I did try to improve it. As a
> matter
> of fact, before making a secure erase of one of the SSDs the write speed was
> under 10MB/s. What you see above is a lot better than what it started out
> (but it's true that after the secure erase the read/write speeds were a lot
> better but it dropped in a very short time frame).
>
> A few points:
> 1. CAUTION: 840 EVO are proved to have a read speed degradation for old
> data written to the drive (this is unrelated to RAID but it probably affects
> performance in RAID).
> 2. I believe that any SSDs, regardless of the brand, in a software RAID-1
> setup
> might be a bad idea.
> 3. I believe that the same SSDs in a hardware RAID setup might lead to a
> different story.
>
> Again: I am not a technical wiz (like many of the people on this list) but I
> did
> have some experience with this so I thought I should let you know.
>
> Kind regards!
>
>
>
>
> On 30.09.2014 17:50, Roberto Spadim wrote:
>>
>> hi guys!
>> i will use a ssd raid1, i want know if raid1 trim is supported at mdadm
>> i will use a 840 evo (or evo pro not selected the right one yet) 500gb
>> each, raid1, today database size is 100gb, i think it will grow
>> 10gb/year, i had many space...
>>
>> the point are: madm raid1 trim is supported? or should i use lvm?
>> should i partition it with 400gb and leave 100gb untouched? or should
>> i use a hdd+ssd and dmcache?
>>
>>
>> :) thanks guys, that's a small enterprise solution, they can't buy
>> raid cards and sas harddisk are same price of ssd :)
>>
>> any idea/experience and information is wellcome
>>
>>
>



-- 
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 16:20   ` Roberto Spadim
@ 2014-09-30 19:58     ` Robert L Mathews
  2014-09-30 20:29       ` Roberto Spadim
  0 siblings, 1 reply; 9+ messages in thread
From: Robert L Mathews @ 2014-09-30 19:58 UTC (permalink / raw)
  To: Linux-RAID

On 9/30/14 9:20 AM, Roberto Spadim wrote:

> well, others experiences and comments are wellcome :)
> comments about cache (bcache,flashcache,dm cache) are wellcome too

Keep in mind that sequential read and write speeds are not everything.
For our use pattern, for example (busy Web and mail servers with
millions of files that aren't necessarily grouped physically on the
disk, even when in the same directory [think maildirs where each file
represents one message]), latency is more important -- particularly read
latency.

Our servers use three-disk RAID 1 arrays. When we replaced one of the
spinning hard drives in each array with an SSD (some of which were
Samsung 840 Pros), then marked the remaining two spinning disks as
"write-mostly", the average read latency on the array dropped from
around 12 ms to less than 2 ms.

More importantly, the average amount of time any process on a server is
waiting in the "D" state (read or write) dropped from 8% to 3%.

Note that improving the read performance this way also improves the
write performance of the entire array, because when a write occurs, it
will never be queued behind a spinning disk read: the spinning disk is
more likely to be idle.

So our experience confirms that adding a single SSD to a RAID 1 array,
then marking the others write-mostly, is a good stopgap measure on the
road to replacing all spinning disks with SSDs. It effectively doubled
the average performance of our storage. No additional caching layers
required.

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 19:58     ` Robert L Mathews
@ 2014-09-30 20:29       ` Roberto Spadim
  0 siblings, 0 replies; 9+ messages in thread
From: Roberto Spadim @ 2014-09-30 20:29 UTC (permalink / raw)
  To: Robert L Mathews; +Cc: Linux-RAID

wow, nice :)
i think that's something near what i have today, the latency is the
main problem that i need to reduce and control, checking every time
with users, they don't care if system is slow to send a big file, they
care if system stop for some seconds and get back, and stop again and
get back, a smothly operation is prefered instead of batchs of high
speed

+1 to this experience, here i have some "D" state process too,
interesting common point

let'me ask others questions....

today you have 3 disk and/or ssd, before you had 3 disks, any time you
got 2 disks setup and tried to change only one disk to ssd? that will
be my scenario if i stay with raid and ssd solution without new cache
layers, about trim commands and this setup life time, there's any
scheduler cleanup method? how many time running this setup? here 1
year is a nice time to consider as a sucessfull project, i replace
disks near to 2 years






2014-09-30 16:58 GMT-03:00 Robert L Mathews <lists@tigertech.com>:
> On 9/30/14 9:20 AM, Roberto Spadim wrote:
>
>> well, others experiences and comments are wellcome :)
>> comments about cache (bcache,flashcache,dm cache) are wellcome too
>
> Keep in mind that sequential read and write speeds are not everything.
> For our use pattern, for example (busy Web and mail servers with
> millions of files that aren't necessarily grouped physically on the
> disk, even when in the same directory [think maildirs where each file
> represents one message]), latency is more important -- particularly read
> latency.
>
> Our servers use three-disk RAID 1 arrays. When we replaced one of the
> spinning hard drives in each array with an SSD (some of which were
> Samsung 840 Pros), then marked the remaining two spinning disks as
> "write-mostly", the average read latency on the array dropped from
> around 12 ms to less than 2 ms.
>
> More importantly, the average amount of time any process on a server is
> waiting in the "D" state (read or write) dropped from 8% to 3%.
>
> Note that improving the read performance this way also improves the
> write performance of the entire array, because when a write occurs, it
> will never be queued behind a spinning disk read: the spinning disk is
> more likely to be idle.
>
> So our experience confirms that adding a single SSD to a RAID 1 array,
> then marking the others write-mostly, is a good stopgap measure on the
> road to replacing all spinning disks with SSDs. It effectively doubled
> the average performance of our storage. No additional caching layers
> required.
>
> --
> Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Roberto Spadim

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 14:50 raid1 - ssd, doubts Roberto Spadim
  2014-09-30 15:46 ` Andrei Banu
@ 2014-10-01  0:36 ` Brassow Jonathan
  2014-10-01  2:01   ` Roberto Spadim
  2014-10-01  7:33 ` David Brown
  2014-10-01  7:50 ` Mikael Abrahamsson
  3 siblings, 1 reply; 9+ messages in thread
From: Brassow Jonathan @ 2014-10-01  0:36 UTC (permalink / raw)
  To: Roberto Spadim; +Cc: Linux-RAID


On Sep 30, 2014, at 9:50 AM, Roberto Spadim wrote:
> the point are: madm raid1 trim is supported? or should i use lvm?
> should i partition it with 400gb and leave 100gb untouched? or should
> i use a hdd+ssd and dmcache?

LVM does not yet support trim on RAID.  (Funny you should ask!  We've just been talking about enabling this in LVM recently and it should go upstream very soon - following into the various distros a little later.)

 brassow

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-10-01  0:36 ` Brassow Jonathan
@ 2014-10-01  2:01   ` Roberto Spadim
  0 siblings, 0 replies; 9+ messages in thread
From: Roberto Spadim @ 2014-10-01  2:01 UTC (permalink / raw)
  To: Brassow Jonathan; +Cc: Linux-RAID

humm interesting , just mdraid1 work with trim :)

other doubt now.. when using ssd+hdd, should trim be enabled at filesystem?

2014-09-30 21:36 GMT-03:00 Brassow Jonathan <jbrassow@redhat.com>:
>
> On Sep 30, 2014, at 9:50 AM, Roberto Spadim wrote:
>> the point are: madm raid1 trim is supported? or should i use lvm?
>> should i partition it with 400gb and leave 100gb untouched? or should
>> i use a hdd+ssd and dmcache?
>
> LVM does not yet support trim on RAID.  (Funny you should ask!  We've just been talking about enabling this in LVM recently and it should go upstream very soon - following into the various distros a little later.)
>
>  brassow



-- 
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 14:50 raid1 - ssd, doubts Roberto Spadim
  2014-09-30 15:46 ` Andrei Banu
  2014-10-01  0:36 ` Brassow Jonathan
@ 2014-10-01  7:33 ` David Brown
  2014-10-01  7:50 ` Mikael Abrahamsson
  3 siblings, 0 replies; 9+ messages in thread
From: David Brown @ 2014-10-01  7:33 UTC (permalink / raw)
  To: Roberto Spadim, Linux-RAID

On 30/09/14 16:50, Roberto Spadim wrote:
> hi guys!
> i will use a ssd raid1, i want know if raid1 trim is supported at mdadm
> i will use a 840 evo (or evo pro not selected the right one yet) 500gb
> each, raid1, today database size is 100gb, i think it will grow
> 10gb/year, i had many space...
> 
> the point are: madm raid1 trim is supported? or should i use lvm?
> should i partition it with 400gb and leave 100gb untouched? or should
> i use a hdd+ssd and dmcache?
> 
> 
> :) thanks guys, that's a small enterprise solution, they can't buy
> raid cards and sas harddisk are same price of ssd :)
> 
> any idea/experience and information is wellcome
> 

With reasonably modern SSD's, don't worry about trim.  Make sure you've
got enough over-provisioning (look at the specs for the SSD - and if
necessary, leave a 5-10% of the space on the disk as unpartitioned free
space).

The main point of trim is to return blocks to the list of blocks
available for recycling - if you have plenty of overprovisioning, this
list (along with the list of blocks already erased) is always going to
have plenty in it.  Thus trim doesn't add anything useful here.

The second effect of trim is to reduce the number of blocks copied
during garbage collection.  As it is unlikely that many extra blocks are
copied, and it is done at off-peak times by the SSD, this makes very
little difference - certainly nothing you would notice in most use-cases.

In other words, you should not notice whether trim is used or not.

Having said that, I believe trim works on raid1 with current kernels.
But make sure you only do off-line trim (fstrim), not the "discard"
mount option in ext4 (or equivalent on other filesystems), as discard
mount will give you noticeably slower performance on many operations.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: raid1 - ssd, doubts
  2014-09-30 14:50 raid1 - ssd, doubts Roberto Spadim
                   ` (2 preceding siblings ...)
  2014-10-01  7:33 ` David Brown
@ 2014-10-01  7:50 ` Mikael Abrahamsson
  3 siblings, 0 replies; 9+ messages in thread
From: Mikael Abrahamsson @ 2014-10-01  7:50 UTC (permalink / raw)
  To: Roberto Spadim; +Cc: Linux-RAID

On Tue, 30 Sep 2014, Roberto Spadim wrote:

> any idea/experience and information is wellcome

Please read the treads in the archives regarding this issue. It's been 
discussed multiple times.

http://board.issociate.de/thread/508953/Re-Software-RAID-and-TRIM.html is 
one of them.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-10-01  7:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-30 14:50 raid1 - ssd, doubts Roberto Spadim
2014-09-30 15:46 ` Andrei Banu
2014-09-30 16:20   ` Roberto Spadim
2014-09-30 19:58     ` Robert L Mathews
2014-09-30 20:29       ` Roberto Spadim
2014-10-01  0:36 ` Brassow Jonathan
2014-10-01  2:01   ` Roberto Spadim
2014-10-01  7:33 ` David Brown
2014-10-01  7:50 ` Mikael Abrahamsson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox