Mounting LVM filesystems the right way?

[Andres_Tarallo]

I'm doing the LABS preparing RHCSA. with RH124 and RH134 labs.

I've noticed that when configurent persistent mount they either add the path to the filesystem or the UUID. I've noticed tha UUID aproach is encouraged, but I want to know the most recommended way of doing this task.

[Chetan_Tiwary_ · Accepted solution]

Hello @Andres_Tarallo !

UUID does resolve a number of problems and is recommended by many cloud solution providers like GCP, Azure, Alibaba etc, eg when you put external drives back in - they may not be named in the same sequence but their UUID be the same.

For a cloud based infrastructure : 
When you start a virtual machine (VM) or attach a device to the system, the Linux kernel assigns a name from a pool of available options. This name can be reused when the device is detached or the VM is stopped. However, upon reattachment or VM restart, a different name might be assigned from the available pool. Since the kernel doesn't guarantee the same name across reboots, relying on these device names can be problematic. Applications and scripts depending on the original name might malfunction, and even the VM itself could fail to boot if relying on a specific device name ( Also this can happen when you use an external device for booting ). This highlights the importance of using alternative identifiers like UUIDs for reliable and consistent system operation.

Here is the official Red Hat documentation recommending UUID ( & labels ) :

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deduplicating_and_comp... 

[Fran_Garcia · Accepted solution]

Hey Chetan,

Filesystems UUID should absolutely not change regardless of where the filesystem resides (lvm, partition, raw disk, etc). The only way to change a filesystem UUID is with filesystem tools (eg: tune2fs -U newUUID /dev/device).

OTOH, disk names (sdX) and WWIDs can definitely change in an environment.

Answering original question:

a) If using LVM, both  /dev/mapper/* and /dev/VGNAME/LVNAME are usually persistent enough to assure you won't run into issues.

b) For non-LVM environments, the UUID can be used (as per the output of blkid).

HTH

Fran

[Chetan_Tiwary_]

Hey @Fran_Garcia , thanks ! That SAN thing was related to the uniqueness of UUID in an ESXi host - agree it wont change on its own. 

[the_Shadowman]

that's actually an interesting question.

Well, the short answer: go UUID way. That's a mainline nowadays, and, at least, it abstracts you from the need to know your ssd connection order.

As you may see already, there's also a long answer)

All this UUID thing is a bit overestimated. As @Chetan_Tiwary_ mentioned, UUID does solve a number of problems. That's true. But in my opinion it simultaneously adds a couple of minor ones.

Determination of disks by their UUIDs is based on two main ideas.

1. Device filenames are prone to being fluid and are going to change often.

2. UUIDs will remain unchanged.

While we are talking about clouds, VMs, all this stuff, both of these assumptions remain true, and everybody is happy. But under some conditions both of these statements can revert to opposite.

Let's land from the clouds onto the shifting sands for a minute. Even on tower desktops we usually don't switch our SSDs too often, do we? So /dev/sda and /dev/sdb covers vast majority of cases.

In notebooks even more so, we typically using just one disk. Two in rare cases, just like in my lovely ASUS NX90.

So there's simply no room for device filename to change.

What about the UUIDs then?

@Fran_Garcia showed us one example of how UUID can be changed, here's another one.

% blkid G sda2 
/dev/sda2: UUID="63d5c701-d9c5-4066-9b98-89df3f33d0d5" TYPE="swap" PARTUUID="0c63d6d7-02"

% sudo mkswap /dev/sda2 
mkswap: /dev/sda2: предупреждение: очистка старой сигнатуры swap.
Setting up swapspace version 1, size = 3,7 GiB (4000313344 bytes)
без метки, UUID=2174469d-330d-4eaa-b3d7-263375cc2e44

% blkid G sda2
/dev/sda2: UUID="2174469d-330d-4eaa-b3d7-263375cc2e44" TYPE="swap" PARTUUID="0c63d6d7-02"

Tada!) UUID is now different, and you will not get your swap mounted without updating your fstab. Using /dev names you wouln't have such problem.

Another assumption within UUID philosophy is that if you re-created an FS, you probably do not need it to be mounted to the same place. And that's an absolutely sane idea, but not for swap filesystems!

I ran into this when I installed another distribution on the 2nd SSD, and wanted to use 2 swap partitions. Installer performed mkswap on a partition which was already in use under the first distro, and did it almost silently. The first OS is now unable to find its swap partition.

I woldn't have this problem usind good'ol /dev/sd{ab} fstab notation. It isn't that bad, and, in some cases works even better.

Allright, guys, with this my long answer I only wanted to discuss the interesting topic, and do not mean to force anyone to agree. I love how the things can be tricky sometimes. Oftentimes)

[2b]

I would say the default /dev/mapper/<vg>-<lv> is good enough for most of the cases.
Renaming VG or LV will break it though. As other people mentioned using UUID is another option, which protects you form issues if VG or LV is renamed but I personally find it a bit "computer-ish", as the UIDs are hard to read and remember.
Great alternative can be Labels. All you need to do is to assign a label to a partition and then mount it using LABEL=<label> in /etc/fstab

https://access.redhat.com/solutions/3599761