Talk:LVM

From ArchWiki
Jump to: navigation, search

systemd services

lvm2 has lvm2-lvmetad.service, lvm2-monitor.service, and lvm2-pvscan@.service. Those should probably be listed with explanations of what they do, and what effects there are from having or not having them running. The wiki does mention lvmetad in the context of its conf file, but not as a systemd service to consider enabling. (Could also mention use_lvmetad = 0 in conf if you don't want it.) Jamespharvey20 (talk) 21:38, 28 July 2015 (UTC)

Yes, yes, YES! A million times YES. I've just spent hours figuring out why my system would hang for 90 seconds on reboot/shutdown. I had a setup with LVM on LUKS where a number of moving parts could be causing it (and were causing it for other people at one point or another) until I figured out... heh... let's leave LUKS out of the picture since it seems to be the culprit and things were working fine. Until I decided to create snapshots of my LVM volumes today before performing a system update and... TADA! It started hanging on reboot/shutdown again. Again, I had a million moving parts that could have been causing it (it's a fresh system that I'm still setting up) and it turns out all I needed was to enable lvm2-monitor... sadly I didn't scroll all the way to the bottom of this wiki page to figure out this could be a problem. I definitely vote to make this a more prominent topic... I don't know if this only affects me but it might be unsuspectingly affecting more people and both degrading their perception of their Arch install as well as getting some data loss. Tiago (talk) 19:10, 1 May 2017 (UTC)
As you discovered, the issue is already documented in the Troubleshooting section - LVM#Delay on shutdown. There's no point in making it more prominent, since manually enabling lvm2-monitor.service should not be the standard practice, it should be enabled by default in lvm2. Vote on FS#50420 and hope the devs will fix it. (Or contact them directly.) -- nl6720 (talk) 07:04, 2 May 2017 (UTC)
Good point, it didn't occur to me that lvm2-monitor.service should be on by default, but reading that bug report makes me really scared that unsuspecting LVM users out there are running their LVM systems without the monitor enabled... Let's just hope the bug gets fixed soon and nobody gets hurt in the process (I upvoted the bug report). --Tiago (talk) 19:57, 2 May 2017 (UTC)

Move physical extents

Ok, I'm confused. This section mentions 92468, 92467 and 92466 PEs. There may be more than one off-by-one error going on here.

Which of these is correct? Ataraxy (talk) 10:35, 28 October 2016 (UTC)Ataraxy

Logical volume types

This section says we should discuss Thin Provisioning here....

Go! Ataraxy (talk) 10:47, 28 October 2016 (UTC)Ataraxy

Create physical volumes

It is written that - "If LVM has to be set on the entire disk, there is no need to create any partitions", and also "DEVICE can be a disk or a partition", but I think it is worth mentioning somewhere in this wiki that GRUB cannot be installed on a disk with LVM installed on it as a whole (see grub-install with LVM on entire disk). Any thoughts? Duduedri96 (talk) 22:57, 30 November 2016 (UTC)

/dev/mapper/*

While reading lvm(8), I noticed: "Links or nodes in /dev/mapper are intended only for internal use and the precise format and escaping might change between releases and distributions. Other software and scripts should use the /dev/VolumeGroupName/LogicalVolumeName format to reduce the chance of needing amendment when the software is updated."

I've been changing /dev/VolumeGroupName/LogicalVolumeName to /dev/mapper/VolumeGroupName-LogicalVolumeName since I don't like that the volume group dirs are directly under /dev/ instead of inside a common subdir. Should we change the paths used in the wiki to use /dev/VolumeGroupName/LogicalVolumeName or just leave them as they are? -- nl6720 (talk) 06:21, 22 April 2018 (UTC)

I vote for /dev/VolGroup/LogicalVol just because it's easier to type and looks better, in my opinion. However, I am a little confused because it seems that people often use /dev/mapper in their /etc/fstab files. Although that could be considered "internal use"? We should identify which parts of the wiki are considered "other software and scripts". -- Wincraft71 (talk) 22:13, 22 April 2018 (UTC)
Interesting, I've always preferred using the /dev/mapper path for clarity too, but the man page does sound pretty clear. That bit and similar ones in other man pages were added in 2014 [1].
I don't really think that usage in fstab is what's considered "internal use". The output of lvdisplay and the Debian and RedHat wikis do use the /dev/group/volume path.
I think we should really change all our examples.
-- Kynikos (talk) 13:03, 23 April 2018 (UTC)
There are probably a lot of pages using /dev/mapper, any chance that a bot could fix them? -- nl6720 (talk)
Hmm I can't think of a way to do it safely, 1) because it's hard-to-impossible, to tell group and volume names apart systematically, and 2) because LVM isn't the only application that uses the device mapper (although it's the only one that I know so far that considers its /dev/mapper paths "only for internal use"). I honestly wonder what kind of global disasters would happen if one day lvm really changed its /dev/mapper/* conventions... -- Kynikos (talk) 14:50, 24 April 2018 (UTC)