From: David Greaves <david@dgreaves.com>
To: Shane <shane@cm.nu>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid5/lvm setup questions
Date: Sat, 05 Aug 2006 18:31:37 +0100 [thread overview]
Message-ID: <44D4D5F9.9080201@dgreaves.com> (raw)
In-Reply-To: <20060805165358.GA29177@cm.nu>
Shane wrote:
> Hello all,
>
> I'm building a new server which will use a number of disks
> and am not sure of the best way to go about the setup.
> There will be 4 320gb SATA drives installed at first. I'm
> just wondering how to set the system up for upgradability.
> I'll be using raid5 but not sure whether to use lvm over
> the raid array.
>
> By upgradability, I'd like to do several things. Adding
> another drive of the same size to the array. I understand
> reshape can be used here to expand the underlying block
> device.
Yes, it can.
If the block device is the pv of an lvm array,
> would that also automatically expand in which I would
> create additional lvs in the new space. If this isn't
> automatic, are there ways to do it manually?
Not automatic AFAIK - but doable.
> What about replacing all four drives with larger units.
> Say going from 300gbx4 to 500gbx4. Can one replace them
> one at a time, going through fail/rebuild as appropriate
> and then expand the array into the unused space
Yes.
or would
> one have to reinstall at that point.
No
None of the requirements above drive you to layering lvm over the top.
That's not to say don't do it - but you certainly don't *need* to do it.
Pros:
* allows snapshots (for consistent backups)
* allows various lvm block movements etc...
* Can later grow vg to use discrete additional block devices without raid5 grow
limitations (eg same-ish size disks etc)
Cons:
* extra complexity -> risk of bugs/admin errors...
* performance impact
As an example of the cons: I've just set up lvm2 over my raid5 and whilst
testing snapshots, the first thing that happened was a kernel BUG and an oops...
David
next parent reply other threads:[~2006-08-05 17:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060805165358.GA29177@cm.nu>
2006-08-05 17:31 ` David Greaves [this message]
[not found] ` <20060805175908.GA31024@cm.nu>
2006-08-05 21:02 ` raid5/lvm setup questions Martin Schröder
2006-08-07 23:29 ` Neil Brown
2006-08-07 19:57 ` Nix
[not found] ` <20060807200455.GA29837@cm.nu>
2006-08-07 20:20 ` Chet McNeill
2006-08-07 22:28 ` David Greaves
2006-08-07 22:32 ` David Greaves
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=44D4D5F9.9080201@dgreaves.com \
--to=david@dgreaves.com \
--cc=linux-raid@vger.kernel.org \
--cc=shane@cm.nu \
/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.