All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Dominic Raferd <dominic@timedicer.co.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: SSD + Rust as raid1
Date: Fri, 07 Jun 2013 18:23:56 -0400	[thread overview]
Message-ID: <51B25D7C.4090403@tmr.com> (raw)
In-Reply-To: <51ADA1AF.6040405@timedicer.co.uk>

Dominic Raferd wrote:
>
> On 31/05/2013 09:52, Dominic Raferd wrote:
>> On 31/05/2013 08:54, Roman Mamedov wrote:
>>> On Fri, 31 May 2013 08:47:00 +0100
>>> Dominic Raferd <dominic@timedicer.co.uk> wrote:
>>>
>>>> This is my idea too (see my OP), but I am concerned about optimisation
>>>> (--write-behind, --bitmap and --bitmap-chunk settings) especially for
>>>> writes.
>>>> --write-behind=16384
>>> I think this will not work, you will have to use 16383.
>> Oh, OK, so 16383 is the maximum then?
>>
>>>> --bitmap=/mnt/sda1/write-intent-bitmap.file
>>> Save yourself lots of maintenance headache, just use --bitmap=internal
>>>
>>>> --bitmap-chunk=256M
>>> Looks OK.
>>>
>> Thanks Roman, but the problem with using --bitmap=internal is that, as
>> Neil Brown posted here on another topic a while ago, this requires a
>> synch write to both devices, and the use-case for which write-behind was
>> developed involved an external bitmap. Hence my plan to use external
>> bitmap file on a fast (SSD-based) separate partition - minimises any
>> slow-down caused by having to maintain the write-intent bitmap file.
>>
>
> I would be very grateful if someone could confirm whether, if I set up RAID1 
> and with one of the drives specify --write-mostly --write-behind=n, that 
> maximum 'n' is 16383, and also whether it is permitted in this configuration 
> to set --bitmap=none and thus avoid the overhead of maintaining a write-intent 
> bitmap file? (My thinking is that for my  needs the extra safety provided by 
> the bitmap file is overkill and the slowing effect (and life-shortening of my 
> SSD) might be more significant.) If I have to have a bitmap file, it is 
> presumably faster to have a larger chunk size, is the maximum permitted 256M?

If you want performance I think a too big chunk size will hurt you. And as I 
understand the way repair on a RAID1 is done, without the bitmap you have a 
chance of the older data on the HDD being used to "correct" the likely better 
data on the SDD.

-- 
Bill Davidsen <davidsen@tmr.com>
   We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination.  -me, 2010



  reply	other threads:[~2013-06-07 22:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 21:23 SSD + Rust as raid1 Dominic Raferd
2013-05-31  0:22 ` Mathias Burén
2013-05-31  7:02   ` Dominic Raferd
2013-05-31  7:30 ` Roman Mamedov
2013-05-31  7:47   ` Dominic Raferd
2013-05-31  7:54     ` Roman Mamedov
2013-05-31  8:52       ` Dominic Raferd
2013-06-04  8:13         ` Dominic Raferd
2013-06-07 22:23           ` Bill Davidsen [this message]
2013-06-08 10:22             ` Roman Mamedov
2013-06-08 17:11               ` Bill Davidsen
2013-06-08 21:58                 ` Roberto Spadim
2013-06-10  8:57                   ` Dominic Raferd
2013-06-01  0:25   ` Stan Hoeppner
2013-06-01  1:19     ` Keith Keller
2013-06-01  4:37       ` Stan Hoeppner
2013-06-07 22:16       ` Bill Davidsen
2013-06-01  1:30     ` Sam Bingner

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=51B25D7C.4090403@tmr.com \
    --to=davidsen@tmr.com \
    --cc=dominic@timedicer.co.uk \
    --cc=linux-raid@vger.kernel.org \
    /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.