From: Andreas Dilger <adilger@turbolinux.com>
To: Jesse Sipprell <jss@evcom.net>
Cc: Andreas Dilger <adilger@turbolinux.com>,
Paul Jakma <paulj@itg.ie>, Jos Visser <josv@osp.nl>,
linux-lvm@marxmeier.com
Subject: Re: [linux-lvm] LVM in shared parallel SCSI environment
Date: Tue, 14 Nov 2000 15:40:43 -0700 (MST) [thread overview]
Message-ID: <200011142240.eAEMehq12172@webber.adilger.net> (raw)
In-Reply-To: <20001114170305.A27524@kevorkian.evcom.net> "from Jesse Sipprell at Nov 14, 2000 05:03:05 pm"
Jesse Sipprell writes:
> > Far safer to simply have a separate VG for each node, and import it on the
> > backup node when you do a failover. Since you have to have some sort of
> > external control for the filesystems, doing the import at the same time is
> > not any more overhead.
>
> Safer, certainly, but won't this make extending/reducing an LV problematic?
> For example, say that in 6 months from now it becomes necessary to move 100MB
> of capacity from LV0 to LV1; now per your assumption that LV0 and LV1 on are
> on separate VGs, one can only extend and/or reduce the involved VGs by this
> amount if the increment/decrement size is a multiple of the PV sizes.
I guess it depends on how your cluster is set up. If you really need to
move that much storage from one node to another, you could simply vgreduce
the one VG by a few disks, and vgextend the other - only affecting the
two nodes you are working on, and also able to do it without taking
either VG offline and with much less risk.
This may be problematic if you have only a single giant RAID device or
similar, unless you carved the RAID into multiple logical disks of a
convenient size (e.g. 10GB or so).
For lesser amounts of storage, I assume that there is at least some
extra space within a VG on any given node.
Of course it's not quite as good as cluster LVM, but much much safer.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
next prev parent reply other threads:[~2000-11-14 22:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-11 13:46 [linux-lvm] LVM in shared parallel SCSI environment Jesse Sipprell
2000-11-14 6:44 ` Jos Visser
2000-11-14 14:38 ` Jesse Sipprell
2000-11-14 16:09 ` Paul Jakma
2000-11-14 19:29 ` Jesse Sipprell
[not found] ` <200011142115.eAELFHV11698@webber.adilger.net>
2000-11-14 22:03 ` Jesse Sipprell
2000-11-14 22:40 ` Andreas Dilger [this message]
2000-11-15 7:04 ` Jos Visser
2000-11-21 13:44 ` Matthew O'Keefe
2000-11-21 18:01 ` John DeFranco
2000-11-21 22:25 ` Jos Visser
2000-11-22 0:42 ` Matthew O'Keefe
2000-11-22 11:40 ` 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=200011142240.eAEMehq12172@webber.adilger.net \
--to=adilger@turbolinux.com \
--cc=josv@osp.nl \
--cc=jss@evcom.net \
--cc=linux-lvm@marxmeier.com \
--cc=paulj@itg.ie \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox