Talk:LVM

From ArchWiki
Revision as of 08:45, 10 April 2019 by Jamespharvey20 (talk | contribs) (→‎lvmetad and linux 5: Add note about merely disabling lvmetad to cause boot failures)
Jump to navigation Jump to 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

I fixed that: https://wiki.archlinux.org/index.php?title=LVM&diff=prev&oldid=557356. = is html for =. The html entity was replaced afterward by an editor. As an aside: how could I wrote that link in a wiki ([[link to diff]]) manner? Regid (talk) 01:59, 27 November 2018 (UTC)
Diffs can be linked with Special:Diff, e.g. Special:Diff/557356. See mw:Help:Diff. -- nl6720 (talk) 13:34, 27 November 2018 (UTC)

Logical volume types

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

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

I was wondering about thin provisioned logical volumes. Just to have a feel what it is about. So I went to https://wiki.gentoo.org/wiki/LVM#Thin_provisioning by following the link to the their wiki at the LVM#See also section. I have only read the beginning of their section, and it's seems a good one. If I were to add the beginning of a LVM#Thin provisioned to this wiki, I would place it between the LVM#Snapshots and LVM#LVM cache, and write:
Thin provisoned logical volume are another way to eploits LVM ability to present a false appearence to the user as if there is more space than in reality. It can be compared to Sparse files. The thin provisioned volume is a volume where its declared disk size may be disjoined from the actual disk size it can occupy. Obviuosly, it will be disasterous when more space than what is realy available will be actually required. So the user should track the usage, and take steps to avoid that situation. In contrast to snapshots, a thin provisioned logical volume does not track any other logical volume contents. The user can write to a thin provisioned logical volume whatever data he wishes to.
Regid (talk) 01:35, 21 December 2018 (UTC)

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)
I think I fixed most of the /dev/mapper usage in English pages.
Only Syslinux#Kernel parameters confused me, is that meant to be an example for LVM on LUKS? I've left it alone for now.
-- nl6720 (talk) 08:16, 29 April 2018 (UTC)
Fantastic job, who needs a bot when there's nl6720? :) About Syslinux, that's just an isolated example, I've simplified it to assume plain LUKS.
Let's leave this discussion open for a while, to make sure that the new convention has ingrained into our habits and we haven't discovered any more examples left unchanged. The next time that somebody reads this it will have been a while and they'll be able to close.
-- Kynikos (talk) 15:19, 30 April 2018 (UTC)

lvmetad and linux 5

I just reverted a change stating that use_lvmetad = 0 must be set in /etc/lvm/lvm.conf because it is deprecated. It's probably fair to call it deprecated, as upstream has made a commit in their unstable branch completely removing it. (And, as most of the LVM developers are with Red Hat, RHEL documentation saying so is decent even though it's not technically from the LVM team.) But, even if it's deprecated, that has no bearing on whether it should be disabled by default. A bugreport was also opened on the lvm2 package asking for this change. See [2] I just made a lengthy reply there, arguing against changing Arch's package yet. These same arguments argue against the change to the Wiki. Upstream LVM, and both their RHEL and Fedora distributions, have neither made lvmetad disabled by default, nor removed it, in their stable release branch. It's still enabled in both. Arch's philosophy is to follow upstream without a darn good reason. There's an upstream bugreport about slowing down boot and shutdown on linux 5 here [3] but they've chosen not to issue a new stable release disabling or removing lvmetad. Note upstream's commit actually removing lvmetad [4] was made last July, but they have chosen not to submit it to their stable branch. With LVM2 being central to data integrity, it's improper for the Arch Wiki to put it the way it was. If someone wants to add a section saying that some Arch users are having success disabling it, IMO, that's OK, as long as it's stated that it's neither tested nor recommended by upstream, and it's at the user's risk. Jamespharvey20 (talk) 08:33, 10 April 2019 (UTC)

Furthermore, merely disabling lvmetad will cause Arch to fail booting, if the root volume is on LVM, after mkinitcpio is ran the next time. The Wiki cannot simply say to disable lvmetad unless the package's lvm2 hook is re-written. And, the Wiki shouldn't say to disable it and manually modify the hook without huge warnings. 08:45, 10 April 2019 (UTC)