From: Peter Rabbitson <rabbit+list@rabbit.us>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Roadmap for md/raid ???
Date: Mon, 19 Jan 2009 19:26:34 +0100 [thread overview]
Message-ID: <4974C5DA.3090806@rabbit.us> (raw)
In-Reply-To: <20090119181919.GB4290@lazy.lzy>
Piergiorgio Sartor wrote:
> Hi,
>
>>> RAID-5/6 with heterogeneous devices.
> [...]
>> 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.
>
> I see your point and I also agree that complexity
> might be too much.
>
> Nevertheless I disagree about the "wasting space",
> since I can see a scenario where there is even
> more wasting.
>
> Let's assume we have a RAID-5 with 7 disks.
> Each time an HD fails, we will replace it with a
> larger one, since this will be cheaper.
> Once we replaced 3 HDs, with could use the unused
> space in RAID-5 again.
> Unfortunately, with the current features, we will
> have to wait to fail all the 7 disks.
> So, with 6 HDs replaced with larger ones, we will
> have a lot of wasted space.
> Of course, unless we did a clever partitioning at
> very the beginning.
>
Or alternatively you use LVM from the start. Then you only need to
"cleverly partition" the new drives, use the first partition in the old
RAID, use the second partition for a new smaller raid, join the new raid
to the VG of the old raid and voilla - no wasted space.
next prev parent reply other threads:[~2009-01-19 18:26 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
2009-01-19 18:19 ` Piergiorgio Sartor
2009-01-19 18:26 ` Peter Rabbitson [this message]
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=4974C5DA.3090806@rabbit.us \
--to=rabbit+list@rabbit.us \
--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 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.