Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #236521 > unrolled thread

Re: add disk to LVM

Started byDavid <bouncingcats@gmail.com>
First post2021-06-27 12:50 +0200
Last post2021-06-27 17:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: add disk to LVM David <bouncingcats@gmail.com> - 2021-06-27 12:50 +0200
    Re: add disk to LVM David <bouncingcats@gmail.com> - 2021-06-27 15:10 +0200
      Re: add disk to LVM Greg Wooledge <greg@wooledge.org> - 2021-06-27 17:40 +0200

#236521 — Re: add disk to LVM

FromDavid <bouncingcats@gmail.com>
Date2021-06-27 12:50 +0200
SubjectRe: add disk to LVM
Message-ID<CuAwq-27u-5@gated-at.bofh.it>
On Sun, 27 Jun 2021 at 19:00, mick crane <mick.crane@gmail.com> wrote:

> hello,
> Please bear in mind that I don't know what I'm doing.
> It looks like when I installed debian on this PC I requested a LVM.
> I'd forgotten about that.

> root@pumpkin:~# df -h
> Filesystem                    Size  Used Avail Use% Mounted on
> udev                          7.8G     0  7.8G   0% /dev
> tmpfs                         1.6G  1.5M  1.6G   1% /run
> /dev/mapper/pumpkin--vg-root   28G  8.4G   18G  33% /
> tmpfs                         7.8G   36M  7.8G   1% /dev/shm
> tmpfs                         5.0M  4.0K  5.0M   1% /run/lock
> /dev/sda1                     236M  155M   69M  70% /boot
> /dev/mapper/pumpkin--vg-home  176G   18G  150G  11% /home
> tmpfs                         1.6G   60K  1.6G   1% /run/user/1000
> /dev/sdb1                     1.8T   62G  1.7T   4%
> /media/mick/a8a2440a-0739-48b3-aa85-29715dbf817d

Hi, the 'df' command shows information about the filesystems
it recognises. But only filesystems. So there's a lot of missing
information, that might be relevant to your question once we
understand exactly what it is. I'll attempt to answer anyway ...

Have a look at the output of 'lsblk -f' to get a comprehensive
display of how all your block devices are being used.

Also it would be helpful to understand your complete LVM
configuration, to see the output of 'vgs', 'pvs' and 'lvs' commands.

If your goal is to be able move the /dev/sdb drive between
different machines, the easiest way is that it should not be used by
LVM at all. That just means it should not participate in any
LVM configuration.

If that is the situation (and hopefully it is what you have, which
the additional information will confirm), then you can simply make
a mountpoint inside any of your other /dev filesystems above, and
use that mountpoint to mount any filesystem that is on /dev/sdb.
Such a mountpoint could be mentioned in /etc/fstab to provide
mount configuration including automounting if that is what you
want.

[toc] | [next] | [standalone]


#236536

FromDavid <bouncingcats@gmail.com>
Date2021-06-27 15:10 +0200
Message-ID<CuCHU-3Ia-7@gated-at.bofh.it>
In reply to#236521
On Sun, 27 Jun 2021 at 22:10, mick crane <mick.crane@gmail.com> wrote:

> root@pumpkin:~# lsblk -f
> NAME   FSTYPE      FSVER    LABEL UUID
> FSAVAIL FSUSE% MOUNTPOINT
> sda
> ├─sda1 ext2        1.0            0a3fac2b-e17e-4be0-8cde-c1d2a3edbc2c
>    68.6M    66% /boot
> ├─sda2
> └─sda5 LVM2_member LVM2 001       xXXSc7-0LNU-hUfb-yqO1-N0Dy-qcDU-GWuDoP
>    ├─pumpkin--vg-root
>    │    ext4        1.0            92a64093-72bc-4a7b-b239-0d9d1cb20679
>    17.6G    31% /
>    ├─pumpkin--vg-swap_1
>    │    swap        1              143694de-2be6-4de8-8731-809a61c0d503
>                 [SWAP]
>    └─pumpkin--vg-home
>         ext4        1.0            bc21377b-ea12-448c-9dde-0789aee937cd
>   149.4G    10% /home
> sdb
> └─sdb1 ext4        1.0            a8a2440a-0739-48b3-aa85-29715dbf817d
>     1.6T     3% /media/mick/a8a2440a-0739-48b3-aa85-29
> sr0
>
> root@pumpkin:~# vgs
>    VG         #PV #LV #SN Attr   VSize    VFree
>    pumpkin-vg   1   3   0 wz--n- <223.33g    0
>
> root@pumpkin:~# pvs
>    PV         VG         Fmt  Attr PSize    PFree
>    /dev/sda5  pumpkin-vg lvm2 a--  <223.33g    0
>
> root@pumpkin:~# lvs
>    LV     VG         Attr       LSize   Pool Origin Data%  Meta%  Move
> Log Cpy%Sync Convert
>    home   pumpkin-vg -wi-ao---- 179.43g
>    root   pumpkin-vg -wi-ao---- <27.94g
>    swap_1 pumpkin-vg -wi-ao---- <15.96g

Ok, now the situation is clear.

'lsblk -f' shows that /dev/sdb is not involved in your LVM.
So you can mount its ext4 filesystem wherever you wish.

It looks like some automounter process has mounted it at
/media/mick/a8a2440a-0739-48b3-aa85-29

That number is the UUID that has been written to the device
filesystem to be able to reliably identify it. That filesystem
itself currently has no ext4 label. You can add a label to it
'e2label /dev/sdb1 mylabel'.

If you want to control where it is mounted at boot time,
something like this in your /etc/fstab should achieve that
UUID=a8a2440a-0739-48b3-aa85-29715dbf817d  /some/mount/point  ext4  noauto

If you prefer instead of UUID=, you could use the e2label command
to give the /dev/sdb1 filesystem a label, and then use syntax
LABEL=mylabel to identify that device in the first argument in
/etc/fstab instead of UUID=...

You can choose /some/mount/point just be sure that it already exists.

'vgs' confirms that there is only one physical volume in your
volume group by "#PV=1".

'pvs' confirms that the only physical volume in your volume group
is /dev/sda5.

This also confirms that the device named /dev/sdb above is not part of
your current LVM configuration. So there's no need to worry about LVM
issues when moving that device around to another machine.

Note that the kernel just happened to refer to this device as 'sdb'
on this boot. Old kernels used to be consistent about this, but the
modern way is that it is not guaranteed to be consistent.
On the next boot it might be named sda or something else. So for that
reason, it's very unwise to specify devices in /etc/fstab using
the '/dev/sdb' notation. That's why I suggest using the UUID or LABEL
syntax in the /etc/fstab example line I gave above.

[toc] | [prev] | [next] | [standalone]


#236545

FromGreg Wooledge <greg@wooledge.org>
Date2021-06-27 17:40 +0200
Message-ID<CuF33-54S-9@gated-at.bofh.it>
In reply to#236536
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.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web