[CentOS] RE: Setting up RAID using mdadm on a proliant DL320 G4

From: centos-bounces at centos.org 
[mailto:centos-bounces at centos.org] On Behalf Of William L. Maltby
> 
> On Wed, 2007-08-29 at 16:38 -0400, Ross S. W. Walker wrote:
> > > From: centos-bounces at centos.org 
> > > [mailto:centos-bounces at centos.org] On Behalf Of 
> > > israel.garcia at cimex.com.cu
> > > 
> > ><snip>
> 
> > ... does anybody knows how to setup a 
> > > software linux RAID on a proliant DL320 G4? 
> > 
> > <snip>
> 
> 
> > When I setup my OS HD in a RAID1 I followed this recipe:
> > <snip>
> 
> > 5) create 4GB LV called swap, formatted swap
> 
> OK. This particular item has aggravated me over many 
> different posts and
> I've withstood the urge to holler "WHY"?
> 
> LVM adds another layer of (unnecessary) overhead. For swap to 
> be usable,
> it must be formatted first, so it can't be expanded 
> on-the-fly with LVM
> in use[1]. Further, expansion on-the-fly can be (effectively)
> accomplished by adding another partition or swap file (ugh! more
> unnecessary overhead) as needed when LVM is not in use.

LVM is hardly any overhead at all.

You could always stop swap, and add more, or like you said create
another swap LV and add it to the mix and later, and here is the
important part, you can REMOVE the swap partition if it proves
unneeded, OR you can stop swapping on it, reduce it, mkswap it
and re-add it.

> Extra swap partitions/files can be easily enabled/disabled as desired
> on-the-fly without the extra overhead.

Like I said there is no real overhead here, everything uses device-mapper
and lvm is all device-mapper.

I have run extensive bench marks on block io on raw disks and block io
on LVs and there was negligible differences maybe 10-20 IOPS on 10K+
IOPS operations.

> What's more, by having multiple swaps predefined and active 
> at different
> priorities at boot-time, unexpected short-term surges in the 
> use of swap
> can be gracefully accommodated. Since this requires no more space, has
> less overhead, is not dependent on anything other than primitive block
> device handling and seems to have as much flexibility and on-the-fly
> growth capability as one could want, I always asked "WHY?".

It doesn't really, once the partitioning of the disk is done, IT IS SET
IN STONE. Everything else you said is true whether your using phyical
disk partitions or LVs.


> I am all ears (although it may not seem so) hoping to learn something
> new.

Better storage management, better hardware abstraction, and in some
cases when used with software raid, better performance, yes better
performance as it provides for some more intelligent re-ordering of
io requests pre-scheduler.

> > <snip>
> 
> [1] Although the mkswap man page discusses the formatting in minimal
> detail, it *appears* that a "tag" and bit-map of used blocks is
> needed/created when mkswap is run. If the vgextend command is used,
> after appropriate pvcreate functions, will the extension be properly
> formatted and used? Since you would not be adding a new swap
> partition/file, but extending an existing one, I suspect that the new
> space may go unused until a rerun of mkswap over the extended volume
> group is done, during which time the swap is not available at all. I
> don't know for sure and am too uninterested to research it 
> that far when
> there seems no benefit from the use of LVM in the first place when all
> the potential benefits of LVM (only extensibility when in the 
> context of
> swap) can be obtained other ways.

Who cares, stop swap, extend the LV and restart swap or just create a
new LV add it and off you go.

In the future once grub can handle booting right into LVs there will
be no more need for physical partitioning at all, create one big VG
out of the system disk and allocate LVs.

Partitioning sucks.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.