From: "'Keld Jørn Simonsen'" <keld@dkuug.dk>
To: GeneralNMX <generalmx@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Properly setting up partitions and verbose boot
Date: Wed, 28 Jan 2009 19:13:49 +0100 [thread overview]
Message-ID: <20090128181349.GA10524@rap.rap.dk> (raw)
In-Reply-To: <20090127042608.GA21425@rap.rap.dk>
On Tue, Jan 27, 2009 at 05:26:08AM +0100, 'Keld Jørn Simonsen' wrote:
> On Mon, Jan 26, 2009 at 11:06:32AM -0500, GeneralNMX wrote:
> >
> > >From my understanding, there is fault tolerance and then there is the chance
> > of a disk dying. Obviously, the more disks you have, the greater chance you
> > have of a disk dying. If we assume all disks start out at some base chance
> > to fail and degrade, putting multiple RAID types on the same disks can
> > dramatically increase the wear & tear as the number of disks increase,
> > especially when you have both a raid5 (which doesn't need to write to all
> > disks, but will read from all disks) and a raid10 (which probably will write
> > and read to all disks) on the same physical array of disks. Since fault
> > tolerance is there to decrease the problems with disks dying, my setup is
> > obviously sub-optimal. Whenever I access my RAID10, I'm also ever so
> > slightly degrading my RAID5 and RAID1, and visa-versa.
>
> Your arrangement does not increase the wear and tear, as far as I can
> tell. This compared to a solution where you only have one big raid10,f2
> raid. Actually your wear and tear would be lower, because raid5 does
> not write so much if you mainly deal with bigger files, and not database
> like operations.
>
Compared to raid10,f2, raid5 only writes 1/3 of the data for redundancyi
in a 4-drive setup, and it does it in a striping manner, so raid5
is quite fast for sequential writing.
> > Now, as for the I/O Wait, this happens when I try to access both the RAID10
> > and RAID5 at the same time, especially if I'm moving a lot of data from the
> > RAID10 to the RAID5.
>
> I think this would be the same if you moved the data (copying it) within
> the RAID10, or within the RAID5. Please try it out, and I would be
> interested also to hear your results.
Of cause moving around big files is IO bound. I think the theoretical
best performance is sequential read time for the one raid, plus
theoretical write time for the other raid, hoping that random read/write
can be minimized. The theoretical read performance for raid10,f2 is
almost 4 times nominal read speed, and theoretical write time for the
raid5 is almost 3 times nominal speed, in your 4-drive setup.
I tried some of it out with "cp", just on a single normal partititon,
and it looks like "cp" minimizes the random read/write.
I would be interested in hearing some performance fugures from you.
Best regards
keld
--
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
prev parent reply other threads:[~2009-01-28 18:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-25 16:18 Properly setting up partitions and verbose boot GeneralNMX
2009-01-26 1:20 ` Keld Jørn Simonsen
2009-01-26 16:06 ` GeneralNMX
2009-01-27 4:26 ` 'Keld Jørn Simonsen'
2009-01-28 18:13 ` 'Keld Jørn Simonsen' [this message]
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=20090128181349.GA10524@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=generalmx@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 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.