At 12:24 PM 9/30/96 -0700, James Graham wrote:
>"Kevin P. Neal" sez:
># >Return-Path: cddukes@unity.ncsu.edu
># >From: cddukes@unity.ncsu.edu
># >Subject: VPS mailing list
># >To: kpneal@pobox.com
># >Date: Sat, 28 Sep 1996 18:43:56 -0400 (EDT)
># >
># >vps-devel@acm.uiuc.edu
># >(And vps-devel-request to manipulate).
># 
># Ok, my friend Chris Dukes wants a LVM-like thing for a free Unix. He's workin
># g
># with the Linux guys on creating one fairly similar to the one found on AIX.
># 
># The question is, is anybody in the BSD world interested in such a thing? It
># would allow lots of neat things, like extendable partitions. Mirroring
># of logical partitions, etc. 
>
>What, aside from extendable partitions, would LVM give us over CCD?
>
>				--*greywolf;

>From an overview of the AIX system that Dukes has lying around in his directory
at NCSU:
>Logical Volume Storage Overview
>A hierarchy of structures is used to manage fixed-disk storage. Each individual
>fixed-disk drive, called a physical volume (PV) has a name, such as 
>/dev/hdisk0. Every physical volume in use belongs to a volume group (VG).
>All of the physical volumes in a volume group are divided into physical
>partitions (PPs) of the same size (by default 2MB in volume groups that
include >physical volumes smaller than 300MB, 4MB otherwise).

>Within each volume group, one or more logical volumes (LVs) are defined.
>Logical volumes are groups of information located on physical volumes. Data
on >logical volumes appears to be contiguous to the user but can be
discontiguous >on the physical volume. This allows file systems, paging
space, and other >logical volumes to be resized or relocated, span multiple
physical volumes, and >have their contents replicated for greater
flexibility and availability in the >Each logical volume consists of one or
more logical partitions (LPs). Each >logical partition corresponds to at
least one physical partition. If mirroring >is specified for the logical
volume, additional physical partitions are >allocated to store the
additional copies of each logical partition. Although >the logical
partitions are numbered consecutively, the underlying physical >partitions
are not necessarily consecutive or contiguous. storage of data.

>When performing a command or procedure on the rootvg, you need to be
familiar >with its unique characteristics. You create a new volume group
with the mkvg >command. You add a physical volume to a volume group with the
extendvg command >and remove it from a volume group with the reducevg
command. Some of the other >commands that you will be using on volume groups
include: change (chvg), list >(lsvg), remove (exportvg), install (
importvg), reorganize (reorgvg), >synchronize (syncvg), make available for
use ( varyonvg), and make unavailable >for use (varyoffvg).

>You may want to create separate volume groups, however, for security
reasons, >because each volume group can have its own security permissions.

I'm not sure what security permissions are used on volume groups.

The document next goes into how you can easily move things around to replace
a disk, for example.

>A quorum is a vote of the number of Volume Group Descriptor Areas and
Volume >Group Status Areas (VGDA/VGSA) that are active. A quorum ensures
data integrity >in the event of a disk failure. 

>When a quorum is lost, the volume group varies itself off so that the disks are
>no longer accessible by the Logical Volume Manager (LVM). This prevents further
>disk I/O to that volume group so that data is not lost or assumed to be written
>when physical problems occur.

>There are cases when it is desirable to continue operating the volume group
>even though a quorum is lost. 

>The most common case for a nonquorum volume group is when the logical
volumes >have been mirrored. When a disk is lost, the data is not lost if a
copy of
>the logical volume resides on a disk that is not disabled and can be accessed.

>If a disk failure occurs, the volume group remains active as long as there
is >one logical volume copy intact on a disk. 

It's a rather long document, and it gets into much detail in some places.

Neat stuff. Resizable partitions, easy mirroring of individual partitions,
reorganizing of partitions with ease. Stability in the event of hardware
going bad in run time. Imagine taking a system down, hooking up a drive,
then booting multi-user mode. In multi-user mode, add partitions and 
filesystems as you like. Rearrange as you like. Minimized down time.

"Help! My home directory partition is full!"

"Hold on a sec.....How's that?"

"Wow! Thanks!"

Sounds like good stuff to me. Much of this is possible to some extent with
AFS, but I think it'd be useful at the disk/filesystem level (in there
somewhere ;).

Note that JFS figures into this somehow, and I'm not very clear on this
(Terry?). I don't know how FFS or ext2fs will fit into it, or if they will.
LFS? (Terry?). Is Margo Seltzer around? (Would she be able to contribute
any ideas?) Her web pages looked cool (I love web pages with white papers
online).

If anybody thinks this is a good idea, but doesn't have time, at least let
me know that somebody else thinks this is neat stuff. 
 
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \   kpneal@pobox.com
XCOMM  "Corrected!" -- Old Amiga tips file  \  kpneal@eos.ncsu.edu
XCOMM Visit the House of Retrocomputing:    /      Perm. Email:
XCOMM     http://www.pobox.com/~kpn/       /   kevinneal@bix.com