public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID types & chunks sizes for new NAS drives
Date: Mon, 22 Jun 2020 21:45:12 -0400	[thread overview]
Message-ID: <24305.24232.459249.386799@quad.stoffel.home> (raw)
In-Reply-To: <rco1i8$1l34$1@ciao.gmane.io>

>>>>> "Ian" == Ian Pilcher <arequipeno@gmail.com> writes:

Ian> I'm replacing the drives in my 5-bay NAS, and planning how I'm
Ian> going to divide them up.  My general plan is to create a matching
Ian> set of partitions on the drives, and then create RAID devices
Ian> across the sets of partitions, for example:

Ian>    md1:  /dev/sdb1  /dev/sdc1  /dev/sdd1  /dev/sde1  /dev/sdf1
Ian>    md2:  /dev/sdb2  /dev/sdc2  /dev/sdd2  /dev/sde2  /dev/sdf2
Ian>     ⋮         ⋮          ⋮          ⋮          ⋮          ⋮
Ian>    md16: /dev/sdb16 /dev/sdc16 /dev/sdd16 /dev/sde16 /dev/sdf16

Ian> This will give me the flexibility to create RAID devices of different
Ian> types, as well as maybe(?) reducing the "blast radius" if a particular
Ian> portion of a disk goes bad.

This is a terrible idea.  Just think about how there is just one head
per disk, and it takes a signifigant amount of time to seek from track
to track, and then add in rotational latecy.  This all adds up.

So now create multiple seperate RAIDS across all these disks, with
competing seek patterns, and you're just going to thrash you disks.  

If you really have two types of data, I'd only setup two partitions at
most, one for your RAID10 (with one hot spare partition) and then
RAID5 or even RAID6 (three data, two parity) on the other five
drives for your bulk data that doesnt' change much.  Say photos,
movies, CDs you've ripped, etc.  

Ian> I believe that it makes sense to use at least 2 different RAID
Ian> levels - RAID-10 for "general" use and RAID-6 for media content.
Ian> Does this make sense?

Sorta kinda maybe... In either case, you only get 1 drive more space
with RAID 6 vs RAID10.  You can suffer any two disk failure, while
RAID10 is limited to one half of each pair.  It's a tradeoff.

Look at the recent Arstechnica article on RAID levels and
performance.  It's an eye opener.

Ian> If so, does anyone have any thoughts or pointers on the chunk
Ian> size, particularly for RAID-10?  (I assume that RAID-6 will have
Ian> similar considerations to RAID-5, and so a large chunk size would
Ian> make sense, particularly for large media files.)

I don't think larger chunk sizes really make all that much difference,
especially with your plan to use multiple partitions.

You also don't say how *big* your disks will be, and if your 5 bay NAS
box can even split like that, and if it has the CPU to handle that.
Is it an NFS connection to the rest of your systems?

Honestly, I'd just setup two RAID1 mirrors with a single hot spare,
then use LVM on top to build the volumes you need.  With 8tb disks,
this only gives you 16Tb of space, but you get performance, quicker
rebuild speed if there's a problem with a disk, and simpler
management.

With only five drives, you are limited in what you can do.  Now if you
could add a pair of mirror SSDs for caching, then I'd be more into
building a single large RAID6 backing device for media content, then
use the mirrored SSDs as a cache for a smaller block of day to day
storage.

But it all depends on what you're going to do.

In any case, make sure you get NAS rated disks, either the newest WD
RED+ (or is it Blue?)  In any case, make sure to NOT get the SMR
(Shingled Magnetic Recording) format drives.  See previous threads in
this group, as well as the arstechnica.com discussion about it all
that they disk last month.  Very informative.

Personally, with regular hard disks, I still kinda think 4gb is the
sweet spot, since you can just mirror pairs of the disks and then
stripe across on top as needed.  I like my storage simple, because
when (not if!) it all hits the fan, simple is easier to recover from.

John

  reply	other threads:[~2020-06-23  1:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-21 16:23 RAID types & chunks sizes for new NAS drives Ian Pilcher
2020-06-23  1:45 ` John Stoffel [this message]
2020-06-23  2:31   ` o1bigtenor
2020-06-23 17:01     ` John Stoffel
2020-06-24 22:13       ` o1bigtenor
2020-06-23 12:26   ` Nix
2020-06-23 18:50     ` John Stoffel
2020-06-23 15:36   ` antlists
2020-06-23 18:55     ` John Stoffel
2020-06-24 12:32     ` Phil Turmel
2020-06-24 14:49       ` John Stoffel
2020-06-24 18:41         ` Wols Lists
2020-06-23 20:27   ` Ian Pilcher
2020-06-23 21:30     ` John Stoffel
2020-06-23 23:16       ` Ian Pilcher
2020-06-24  0:34         ` John Stoffel

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=24305.24232.459249.386799@quad.stoffel.home \
    --to=john@stoffel.org \
    --cc=arequipeno@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox