From: Neil Brown <neilb@suse.de>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Roadmap for md/raid ???
Date: Mon, 19 Jan 2009 12:40:12 +1100 [thread overview]
Message-ID: <18803.55804.905420.503480@nbeee.brown> (raw)
In-Reply-To: message from Piergiorgio Sartor on Sunday January 11
On Sunday January 11, piergiorgio.sartor@nexgo.de wrote:
> Hi,
>
> something else you can add to your "todo list",
> or not, as you like.
>
> RAID-5/6 with heterogeneous devices.
> The idea would be to build a RAID-5/6 with devices
> of different size, but using, whenever possible,
> the complete available space.
> Example: let's say we have 6 HDs, 3x 500GB and 3x 1TB.
> The idea is to have a single md device, in RAID-5,
> where the first part of the device (500GB range) uses
> the whole 6 HDs, while the second part uses only 3.
> Specifically, the first part will have 500GB x5
> and the second 500GB x2.
> This is already doable by partitioning the HDs properly
> before and creating 2 md devices.
> Nevertheless, given the "grow" possibility, in both
> directions (disk number, disk size), the RAID only
> solution would be interesting.
I've thought about this occasionally but don't think much of the idea.
It seems nice until you think about what happens when devices fail
and you need to integrate hot spares.
Clearly any spare will need to be as big as the largest device.
When that get integrated in place of a small device, you will be
wasting space on it, and then someone will want to be able to
grow the array to use that extra space, which would be rather
messy.
I think it is best to assume that all devices are the same size.
Trying to support anything else in a useful way would just add
complexity with little value.
>
> RAID-5/6 pre-caching. Maybe this one is already there, in any case
> the idea would be to try to cache a complete stripe set, in case of
> RAID-5/6, in order to avoid sub sequent reads in case of write.
> This could be a user switchable parameter, for example when the user
> knows there will be a lot of read-modify-write to the array.
We already do some degree of caching. This primarily exists so that
we can be working on multiple stripes at once. If there are multiple
write accesses to a stripe while it stays in cache you could save some
reads, but I suspect that most times stripes fall out of cache before
they are used again. That cache can be made bigger, but I'm not sure
it would help a lot..
Thanks for the ideas.
NeilBrown
next prev parent reply other threads:[~2009-01-19 1:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-19 4:10 Roadmap for md/raid ??? Neil Brown
2008-12-19 15:44 ` Chris Worley
2008-12-19 15:51 ` Justin Piszcz
2008-12-19 16:13 ` Bernd Schubert
2008-12-30 18:12 ` Janek Kozicki
2008-12-30 18:15 ` Janek Kozicki
2009-01-19 0:54 ` Neil Brown
2009-01-19 12:25 ` Keld Jørn Simonsen
2009-01-19 19:03 ` thomas62186218
2009-01-19 20:00 ` Jon Nelson
2009-01-19 20:18 ` Greg Freemyer
2009-01-19 20:30 ` Jon Nelson
2009-01-11 18:14 ` Piergiorgio Sartor
2009-01-19 1:40 ` Neil Brown [this message]
2009-01-19 18:19 ` Piergiorgio Sartor
2009-01-19 18:26 ` Peter Rabbitson
2009-01-19 18:41 ` Piergiorgio Sartor
2009-01-19 21:08 ` Keld Jørn Simonsen
2009-01-14 20:43 ` Bill Davidsen
2009-01-19 2:05 ` Neil Brown
[not found] ` <49740C81.2030502@tmr.com>
2009-01-19 22:32 ` Neil Brown
2009-01-21 17:04 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2008-12-19 9:01 Aw: " piergiorgio.sartor
2008-12-19 17:01 ` Dan Williams
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=18803.55804.905420.503480@nbeee.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=piergiorgio.sartor@nexgo.de \
/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;
as well as URLs for NNTP newsgroup(s).