This is exactly where LVM comes in.
You set up a "Volume Group". This can combine multiple disks (or even
partitions) into a single logical unit, which you then work with as a
single "disk". The articles I indicated outline the philosiphy of
Logical Volumes & Volume Groups much better than I will try to do here.
But to really shorten it up:
Say you had a system with 3 disks in it.
Say you wanted one of them for root (/, /usr/, /var . . . etc..), and
the other two for data.
You "could" leave the first as is, and install the system on it (yes,
you could make it a volume group too, but let's keep this simpler than
that).
Once the system is installed (ignoring the other two disks during the
install). You could create a single "Volume Group" encompasing both
those disks into a single logical unit.(you would do this without
creating any partitions on the disks first!!).
Then create "Logical Volumes" on the disks. (these would be a logical
replacement for partitions). Then create your filesystems on the logical
volumes. (once you get your head around logical volume management it all
makes a lot of sense).
Why do this you ask?
If those two drives were 9GB each, you would essentially have a single
"logical" dirve of 18 GB, and you would work with it that way.
More importantly:
If you didn't allocate ALL 18GB to start out with. Let's say you built
logical volumes & filesystems like so:
/opt
5GB
/usr/src
4GB
/usr/local
4GB
And saved the rest for later use (with this, you don't have to (or want
to) "partition" the whole disk).
Well, later arrives, and you discover that /usr/src is growing way too
fast, and you need more space (sound familiar?).
You can go in, and expand the logical volume, and then the filesystem
that's sitting on it (if you have an expandable filesystem. I would
recomend either XFS, or JFS. But some like ReiserFS).
Oh.. and you can expand the filesystem, "without" rebooting the box!
Then later, you learned that you need a new filsystem. Say the customer
wants a filesystem for off the shelf software.
Easy:
Create a new Logical volume on the exta space on that volume group, and
build a filsystem on it. Again, without rebooting.
Oops.. Don't need that new fielsystem... Delete it. Again: without
rebooting...
hmm.. filled up that volume group.
On SCSI? Good news. You can add disks to the volume group. (ok, you'll
probably have to power the box down for this one to do the physical
connection), but once it's in, you're back in business, adding &
subtracting filesystems while the box is running.
If you're not familar with Logical Volume Management, it can take some
time to get your head around. But once you get it, it's well worth the
investment in time. This is fairly new to Linux, but it's been with the
big boys for a long time. Starting with IBM on AIX several years ago.
Spend some time at the links I provided. If you're running a production
server, with lots of disks in it, you'll be glad you did.
Also, take a look at journaled filesystems. Again, with a production
box, with lots of disks, well worth the investment in time.
Ric
David E. Fox wrote:
>>I used to use Novell Netware and I could used to be able to merge two disk
>>volumes (disk partions±) together, to create a large volume (i.e. 10gb on
>>HD1 + 20Gb on HD2) could give me a 30Gb volume.
>>
>
> I am not sure if you can *physically* merge the two partitions into one
> physical volume. But you may not need to do this.
>
> The Unix (linux too) file system allows you to physically mount separate
> drives / partitions underneath a tree, and the result is that all the
> files on those partitions appear beneath the directory you mounted the
> partitions on (the mount point).
>
> For instance, the root of all filesystems is '/' in a Unix system. Under-
> neath that, you might have /usr, /home, /var, /tmp, etc. These directories
> could either be hosted on one large partition, or be spread over several
> smaller partitions. Suppose you put /home on a separate partition - then when
> you mounted that disk on /home, you'd just be attaching its files to the main
> directory tree at '/'. Someone going into /home/dfox/whatever/junk/ would be
> actually getting files from another disk & partition.
>
>
>>Is it possible to do the same with Linux? What I mean I create a directory
>>called /work and then I mount two 40gb discs in this partition to give me
>>
>
> If you separated the two logically, you could have
>
> /work/disk1
>
> and
>
> /work/disk2
>
> both on the filesystem. Each disk would be mounted on either disk1 or disk
> 2. Unfortunately, you can't mount both filesystems on one mount point.
>
> Through some creative (and perhaps complex) mapping schemes (done with
> symbolic links) you can make it *appear* that both filesystems are mapped
> to various entries in /work transparently, and make it look like you have
> one large area when in reality, you have two (or more) smaller and physically
> separate areas underneath /work. How you organize that is very dependent on
> how your data is stored. For example, if you organized your data based on
> months, you could have January through June on one disk, and July through
> December on the second.
>
>
>>Also, how can I turn a directory / file stucture into an ISO image.
>>
>
> Well, are you referring to burning an ISO image through cdrecord or some
> other tool?
>
>
>>Also, is it possible to mount to ISO images in the same directory. For
>>example I create the directory /Mandrake and the I mount the two ISO images
>>for LM8 in the SAME directory?
>>
>
> Not at the same mount point. But I'm not sure why you'd need to do this.
> The best I think you could do is to 'loopback mount' the two ISO images
> underneath separate directories underneath Mandrake, for instance
> Mandrake/image1 and Mandrake/image2.
>
> ------------------------------------------------------------------------
> David E. Fox Thanks for letting me
> [EMAIL PROTECTED] change magnetic patterns
> [EMAIL PROTECTED] on your hard disk.
> -----------------------------------------------------------------------
>
>
