From: Jesse Sipprell <jss@evcom.net>
To: linux-lvm@msede.com
Subject: [linux-lvm] LVM in shared parallel SCSI environment
Date: Sat, 11 Nov 2000 08:46:02 -0500 [thread overview]
Message-ID: <20001111084602.B26544@kevorkian.evcom.net> (raw)
Hi all,
I'm currently in the process of planning a large(ish)-scale Linux deployment.
As part of the planning process, I am considering using LVM in a shared SCSI
environment; potentially with GFS as the file system in the future, but
starting with ext2.
To that end I have a test "cluster" set up. It consists of:
One Winchester Systems OpenRAID chassis with 100GB total storage, running in
RAID5. The OpenRAID is a SCSI-to-SCSI solution, with four host SCSI channels.
The hardware can be configured so that the channels can share physical storage
space.
Four test Linux boxes, each with a small (9GB) boot/root/swap/emergency SCSI
disk. Obviously, the four boxes are connected to the four host channels on
the OpenRAID.
The OpenRAID is configured such that all available disk space is visable
identically to the servers. Obviously, because the initial test uses ext2
instead of a filesystem that supports shared media (i.e. GFS), we won't be
actually sharing filesystems between boxes. However, LVM seemed like a pretty
good potential in this situation because it allows for relatively dynamic
allocation of storage from a large shared "pool." The catch, as with all
shared SCSI solutions, is that each participating host must maintain a
consistant view of LVM metadata.
So far, it's been fairly successful. Once the vg and lvs are created, and each
host has meta in core, all is well. The only problem I am seeing is when an
lv (for example) is extended or reduced, the other systems are unaware of the
change in LVM metadata. This makes sense of course, because each host is
operating with it's own "notion" of the LVM in core. The solution is rather
awkward; one has to unmount all LVM filesystems on each host, vgchange the vg
to inactive, vgchange it back to active and then remount the filesystems.
My question is this: Is there any way to "refresh" the in-core metadata from
disk? If not, does anyone think this might be a good idea for the future?
Regards,
--
Jesse Sipprell
Technical Operations Director
Evolution Communications, Inc.
800.496.4736
* Finger jss@evcom.net for my PGP Public Key *
next reply other threads:[~2000-11-11 13:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-11 13:46 Jesse Sipprell [this message]
2000-11-14 6:44 ` [linux-lvm] LVM in shared parallel SCSI environment 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
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=20001111084602.B26544@kevorkian.evcom.net \
--to=jss@evcom.net \
--cc=linux-lvm@msede.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox