All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Lombard <hal@mailgate.net>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] expanding physical disks
Date: Fri, 15 Jun 2001 17:57:38 +0200	[thread overview]
Message-ID: <20010615175738.F21571@hal.mailgate.net> (raw)
In-Reply-To: <20010615165135.A4266@sistina.com>; from Mauelshagen@sistina.com on Fri, Jun 15, 2001 at 04:51:35PM +0200

On Fri, Jun 15, 2001 at 04:51:35PM +0200, Heinz J. Mauelshagen wrote:
> On Fri, Jun 15, 2001 at 04:11:51PM +0200, Hugo Lombard wrote:
> > 
> > If you're using LVM primarily as a way to make it possible for you to
> > expand your storage space on-line (and on-mount-point) wouldn't it be
> > "easier" to _just_ use the RAID? i.e. expand the RAID volume on the
> > controller, so basically the "disk" is bigger now, and the just "grow"
> > your partition, extend your filesystem, and that's it?
> 
> I think you're right in case you can live with the restrictions involved.
> 

I'm right!?!?! Mother would be so proud!! ;)

> If the amount of resizable volumes a single smart controller can support is
> enough, you can surely go with that solution. When it comes to more storage
> you need a logical volume manager to group multiple disk subsystems together
> in order to support large storage configurations.
> 

*nod*  As usual, there's no universal answer, and it depends on you
needs/configuration/preference/phase of moon...

> > 
> > It's a thought I've been toying with since seeing the IBM ServeRAID's
> > capability to grow volumes.  I've not attempted any testing though, so
> > this is pure speculation...
> > 
> > (PS: All this means nothing if you're using LVM for it's other
> > features, like striping, but then the RAID can do that too...)
> 
> Plus LVM's features to move data around online in order to relocate it to
> faster/bigger/newer disk subsystems, to have more that just a couple of 
> resizable devices, support for hardware block device reconfiguration without
> any changes in the namespace of the logical volumes, snapshot support etc.
> 

Very important features to consider, for sure.

-- 
Dorothy:	But how can you talk without a brain?
Scarecrow:	Well, I don't know... but some people without brains
		do an awful lot of talking.
		-- The Wizard of Oz
---------------------------------------------------------------------------
 Hugo Lombard                    Infoline (Pty) Ltd
 System Administrator
---------------------------------------------------------------------------

  reply	other threads:[~2001-06-15 15:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-13  4:28 [linux-lvm] expanding physical disks Brian J. Murrell
2001-06-13  7:10 ` Andreas Dilger
2001-06-13 13:20   ` Luca Berra
2001-06-15 14:11     ` Hugo Lombard
2001-06-15 14:51       ` Heinz J. Mauelshagen
2001-06-15 15:57         ` Hugo Lombard [this message]
2001-06-13 17:22   ` Paul Jarc
2001-06-15 10:29     ` Heinz J. Mauelshagen

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=20010615175738.F21571@hal.mailgate.net \
    --to=hal@mailgate.net \
    --cc=linux-lvm@sistina.com \
    /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.