From: "Heinz J. Mauelshagen" <Mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] expanding physical disks
Date: Fri, 15 Jun 2001 12:29:37 +0200 [thread overview]
Message-ID: <20010615122937.B3318@sistina.com> (raw)
In-Reply-To: <m3ofrsguqf.fsf@multivac.cwru.edu>; from prj@po.cwru.edu on Wed, Jun 13, 2001 at 01:22:26PM -0400
On Wed, Jun 13, 2001 at 01:22:26PM -0400, Paul Jarc wrote:
> Andreas Dilger <adilger@turbolinux.com> writes:
> > Brian Murrell writes:
> >> How does LVM deal with physical disks that can get bigger or smaller,
> >> such as a hardware RAID device?
> >
> > Doesn't work at this time. LVM will only see what was originally there
> > at the time pvcreate was run (or possibly vgcreate/vgextend).
>
> But it won't do any harm either, right?
>
> > If the new PEs don't all fit into the padding space (it may happen if
> > your starting PV size is just a couple hundred kB over n * PE size),
> > then you will need to pvmove PE0 from its current location to somewhere
> > else in the VG, and then renumber all of the PEs on that PV as (PE# - 1).
> > That couble be ugly because I believe the PE number is stored in the
> > snapshot tables and such.
>
> Since this is a case of making the PV bigger, all the PEs could simply
> be shifted by one; there is, after all, more room at the end now.
> That would still be ugly, though.
Yes, it would :-(
Typical HW storage subsystems anable you to create additional IDs (for eg.
SCSI LUNs) to addrees the gained storage once you insert additional drives.
Do you have constraints to create those and just use the as new PVs or
is the maximum of 8 LUNs in the SCSI case insufficient for you?
That's the way we did it quite happily for multiple years in my previous job
on HP, SUN and other platforms :-)
>
>
> paul
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2001-06-15 10:29 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
2001-06-13 17:22 ` Paul Jarc
2001-06-15 10:29 ` Heinz J. Mauelshagen [this message]
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=20010615122937.B3318@sistina.com \
--to=mauelshagen@sistina.com \
--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.