All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Keld Jorn Simonsen <keld@keldix.com>,
	Wil Reichert <wil.reichert@gmail.com>,
	linux raid <linux-raid@vger.kernel.org>
Subject: Re: SSD & mechanical disc in RAID 1
Date: Mon, 01 Feb 2010 15:06:32 -0500	[thread overview]
Message-ID: <4B673448.4080002@tmr.com> (raw)
In-Reply-To: <87bpgmyu37.fsf@frosties.localdomain>

Goswin von Brederlow wrote:
> Keld Jørn Simonsen <keld@keldix.com> writes:
>
>   
>> On Sat, Jan 09, 2010 at 09:53:11AM -0800, Wil Reichert wrote:
>>     
>>> Has anyone ever tried putting an SSD and a mechanical disc in RAID 1
>>> using write-mostly?  The goal would be to extol the speed & latency
>>> virtues of an SSD while retaining the integrity of the traditional
>>> storage.  Would this setup even work as I expect it to?
>>>       
>> I think you are better served by trying out RAID10 in the far or offset
>> layouts. RAID1 would per se not gain from the low latency times of 
>> SSD. RAID1 should function the same with hard disk as with SSD, 
>> and with hard disk it would not make sense to multiplex reading
>> of a file, as skipping and reading a block essentially takes the same
>> time.
>>
>> Best regards
>> Keld
>>     
>
> With raid10 in the far or offset layout every (large) read and write
> would always access both the SSD and rotating disk. That would make
> every operation wait for the rotating disk to seek.
>
>
> I think his initial idea of raid1 is verry good. With write-mostly all
> reads should come from the fast SSD. I would also add write-behind.
> That way writes will not wait for the rotating disk and get the full
> SSD speed as well.
>   

I had an SSD waiting to be deployed, and I tried putting a journal on it 
and using a mount with data=journal. Supposedly when the data is written 
to the journal the write will be "complete" and effective write speed 
for many small random writes will be higher. I don't have the results 
handy, but they were not so great that I went out and got another SDD.

-- 
Bill Davidsen <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein


--
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

  parent reply	other threads:[~2010-02-01 20:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-09 17:53 SSD & mechanical disc in RAID 1 Wil Reichert
2010-01-09 19:23 ` Keld Jørn Simonsen
2010-01-22 16:37   ` Goswin von Brederlow
2010-01-31 20:21     ` Aryeh Gregor
2010-02-01 20:56       ` Wil Reichert
2010-02-01 20:06     ` Bill Davidsen [this message]
2010-02-01 21:10 ` David Rees
2010-02-02 14:07   ` Aryeh Gregor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B673448.4080002@tmr.com \
    --to=davidsen@tmr.com \
    --cc=goswin-v-b@web.de \
    --cc=keld@keldix.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=wil.reichert@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.