Re: add disk to LVM
On Sun, Jun 27, 2021 at 04:01:07PM +0100, mick crane wrote:
> got it about the labels/UUIDs I think but I think I'm confusing myself here.
> The file system doesn't know anything about the LVM ?
> The LVM takes care about how and where data is stored on disk.
> What is lv root the file system thinks is /
> The file system thinks /home is part of / but the LVM puts anything in /home
> to its "lv home" ?
Let's take a step back.
Let's say you've got a disk, and it can hold 1 megabyte of data. You've
added it to your system, hardware-wise, by connecting cables and stuff.
What are you going to do next?
You need to tell the operating system how to use this new storage device.
The Unix paradigm here is that you create a file system on the device,
and then "mount" it somewhere.
("Mounting" is a word that comes from the old reel-to-reel tape drives,
which you may have seen in movies and TV shows from the 1960s. The tape
drives are large cabinets that stand vertically, with two pegs sticking
out. When you want to read data from a tape, you have to take the tape
out of its protective case, and hang it on one of the pegs. This is
called "mounting" the tape.)
In the paradigm of file systems, what it really means is "making this
storage device available for use", and the primary question is *where*
you mount it -- meaning, what subdirectory name. Maybe you need more
space for user home directories, but you've already got a disk mounted
at /home. You could decide to mount the new disk at /home2 and then
move some of the users from /home to /home2. Or any number of other
possible arrangements. That's the system administrator's decision.
When disks were roughly 1 megabyte in size, this was all you needed to
know. The disk would hold one file system, because it didn't make any
kind of sense to use just *part* of a disk. They're so small!
But later on, disks got bigger. Instead of one system having several
disks attached to it in order to accomodate all of the storage you needed,
you'd have a system with just *one* huge disk in it.
At that point, a new paradigm emerged: dividing up a single disk into
sections, with each section having a different purpose.
There are a few different ways this was done, depending on the design
decisions made by the companies involved. In the home computer market,
you had CP/M and later MS-DOS, and those operating systems used something
called "partitions". A given disk could be divided up into 1 to 4
partitions, and each partition was referenced by a letter of the
alphabet. "A" and "B" were typically reserved for two removable media
("floppy") drives, and then "C", "D" and so on were used for fixed disk
partitions.
Linux adopted this, which makes sense, as Linux was primarily marketed
to run on the same personal computers that ran MS-DOS. Being able to
use the same disks, and even share them between Linux and MS-DOS, was
a logical step.
Over in the Unix world, some of the vendors (I'm thinking primarily of
Hewlett Packard) came up with a different scheme. Instead of using
"partitions" from the home computing world, they decided to implement
a much fancier abstraction layer. Under this paradigm, you wouldn't
divided up a disk into physical sections and put a file system on each
section. Rather, disks would be aggregated into pools, with each pool
acting as a "virtual disk". Then, each pool could be divided up into
sections, which would act like "virtual partitions". But at the actual
physical layer, a given "virtual partition" might exist across more than
one physical disk.
HP called this the Logical Volume Management system, or LVM.
Linux adopted it, with basically no incompatible changes whatsoever.
If you've ever administered an HP-UX machine with LVM, you'll be right
at home with the Linux version.
So, now Linux has two different ways that you can slice up a physical
disk device to hold more than one file system: you can use MS-DOS style
partitioning, or you can use HP-UX style Logical Volumes.
In fact, you can even combine the two -- you can create an MS-DOS style
partition for something like /boot, and then create a second partition
and use that as the physical layer underneath an HP-UX style LVM setup,
with all of your other file systems living in the LVM paradigm.
Now, let's go back to your questions:
> The file system doesn't know anything about the LVM ?
A file system can be created on a partition, or on a Logical Volume.
The file system doesn't need to know anything about the device it lives
on.
If you want the file system to be mounted in a fixed location at boot
time, you add an entry in /etc/fstab to tell the system which device
should be mounted where. The devices can be referenced by their
device names (but these can change over time, so it's not recommended),
or by their file system UUIDs, or by human-readable labels that you give
them.
> The LVM takes care about how and where data is stored on disk.
LVM is one of the ways you can slice up a disk to hold multiple
organizations of data (file systems). It's not the only way. In fact
it's an uncommon choice on desktop systems. It's more common on servers.
Of course, the system administrator is free to choose whatever they like.
> What is lv root the file system thinks is /
Your root file system can be on a Logical Volume. Some systems are
installed that way. Some are not.
> The file system thinks /home is part of / but the LVM puts anything in /home
> to its "lv home" ?
This depends on whether you've mounted a separate file system at /home.
You can determine whether this is the case by running "df /home".
It'll tell you whether the file system that's currently represented
by the /home directory is part of the / (root) file system, or mounted
separately as /home.
On my computer, I have a separate /home, so I see this:
unicorn:~$ df /home
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda8 23899984 15466676 7196216 69% /home
If yours does *not* have a separate /home, the last field of the last
line of output will be / instead of /home.
Whether the file system is on LVM or a partition doesn't change how it
acts, from the end user's point of view. Files are stored and retrieved
by their pathnames (e.g. /home/susan/.bash_profile) and the underlying
storage choice makes no visible difference to the end user.
Reply to: