[arch-dev-public] Big changes to LVM2 in testing
I discovered some new awesomeness in LVM2 (okay, not THAT new, but still, so far unknown to me). In our lvm2 package, I enabled lvmetad - this is a metadata caching daemon that reacts to events from udev. I completely reorganized our systemd and mkinitcpio lvm integration: * lvm.service and lvm-on-crypt.service are gone. * Once you install lvm2, lvmetad.socket and dmeventd.socket are always active in systemd. * If you need LVM monitoring, you need to enable lvm-monitoring.service (recommended if you use LVM, even if you don't know if you need monitoring). I didn't enable this by default because it would always start lvmetad.service. * LVM is fully hotplugged via udev. You don't need to activate anything, LVM volumes will just work. LVM no longer requires systemd-udev-settle.service and all the race conditions should be gone. * LVM in mkinitcpio is also fully hotplugged, lvmwait= is now a no-op. However, LVM in mkinitcpio now requires the udev hook. This requires that the use_lvmetad = 1 option is set in /etc/lvm/lvm.conf - this is now the default, but a .pacnew must be merged if it exists. You can restrict the hotplugging of the volume groups with the auto_activation_volume_list option in lvm.conf. If you uncomment that, only the listed volumes will be enabled. This is commented out by default. WARNING: If you have any incomplete or clustered volume groups, none of this will work yet! However, I doubt any Arch user uses that.
On 1 November 2012 02:05, Thomas Bächler
I discovered some new awesomeness in LVM2 (okay, not THAT new, but still, so far unknown to me).
In our lvm2 package, I enabled lvmetad - this is a metadata caching daemon that reacts to events from udev. I completely reorganized our systemd and mkinitcpio lvm integration:
* lvm.service and lvm-on-crypt.service are gone. * Once you install lvm2, lvmetad.socket and dmeventd.socket are always active in systemd. * If you need LVM monitoring, you need to enable lvm-monitoring.service (recommended if you use LVM, even if you don't know if you need monitoring). I didn't enable this by default because it would always start lvmetad.service. * LVM is fully hotplugged via udev. You don't need to activate anything, LVM volumes will just work. LVM no longer requires systemd-udev-settle.service and all the race conditions should be gone. * LVM in mkinitcpio is also fully hotplugged, lvmwait= is now a no-op. However, LVM in mkinitcpio now requires the udev hook.
This requires that the use_lvmetad = 1 option is set in /etc/lvm/lvm.conf - this is now the default, but a .pacnew must be merged if it exists.
You can restrict the hotplugging of the volume groups with the auto_activation_volume_list option in lvm.conf. If you uncomment that, only the listed volumes will be enabled. This is commented out by default.
WARNING: If you have any incomplete or clustered volume groups, none of this will work yet! However, I doubt any Arch user uses that.
I think this deserves a post to the news sections, if you do not plan to do that already. Anyway, good work, I like these changes (getting rid of the race conditions is a nice bonus). Lukas
Am 01.11.2012 16:50, schrieb Lukas Jirkovsky:
I think this deserves a post to the news sections, if you do not plan to do that already.
Why? The essential information is in the post_install and everything will "just work" after the change (except maybe monitoring).
On 1 November 2012 16:54, Thomas Bächler
Am 01.11.2012 16:50, schrieb Lukas Jirkovsky:
I think this deserves a post to the news sections, if you do not plan to do that already.
Why? The essential information is in the post_install and everything will "just work" after the change (except maybe monitoring).
Mostly because people are incorrigible and a lot of them ignores the install messages and sometimes they just miss it when updating more packages at one (even though in this case the message is rather long, so it should be left unnoticed). Also in my opinion it's always good to inform users that good things are going to happen. Users like such news. But that's just my 2¢ Lukas
On Wed, Oct 31, 2012 at 9:05 PM, Thomas Bächler
I discovered some new awesomeness in LVM2 (okay, not THAT new, but still, so far unknown to me).
In our lvm2 package, I enabled lvmetad - this is a metadata caching daemon that reacts to events from udev. I completely reorganized our systemd and mkinitcpio lvm integration:
* lvm.service and lvm-on-crypt.service are gone. * Once you install lvm2, lvmetad.socket and dmeventd.socket are always active in systemd. * If you need LVM monitoring, you need to enable lvm-monitoring.service (recommended if you use LVM, even if you don't know if you need monitoring). I didn't enable this by default because it would always start lvmetad.service. * LVM is fully hotplugged via udev. You don't need to activate anything, LVM volumes will just work. LVM no longer requires systemd-udev-settle.service and all the race conditions should be gone. * LVM in mkinitcpio is also fully hotplugged, lvmwait= is now a no-op. However, LVM in mkinitcpio now requires the udev hook.
This requires that the use_lvmetad = 1 option is set in /etc/lvm/lvm.conf - this is now the default, but a .pacnew must be merged if it exists.
You can restrict the hotplugging of the volume groups with the auto_activation_volume_list option in lvm.conf. If you uncomment that, only the listed volumes will be enabled. This is commented out by default.
WARNING: If you have any incomplete or clustered volume groups, none of this will work yet! However, I doubt any Arch user uses that.
If you use both RAID and LVM, make sure that you use the mdadm_udev hook instead of the mdadm one. I had to do this change to make my system boot with the lvm2 package in [testing].
Am 03.11.2012 02:40, schrieb Eric Bélanger:
You can restrict the hotplugging of the volume groups with the auto_activation_volume_list option in lvm.conf. If you uncomment that, only the listed volumes will be enabled. This is commented out by default.
WARNING: If you have any incomplete or clustered volume groups, none of this will work yet! However, I doubt any Arch user uses that.
If you use both RAID and LVM, make sure that you use the mdadm_udev hook instead of the mdadm one. I had to do this change to make my system boot with the lvm2 package in [testing].
In a RAID->LVM setup, this shouldn't matter. If it does, I don't understand why. However, a LVM->RAID setup will be broken (do you use that? does anyone?).
Am 03.11.2012 02:40, schrieb Eric Bélanger:
If you use both RAID and LVM, make sure that you use the mdadm_udev hook instead of the mdadm one. I had to do this change to make my system boot with the lvm2 package in [testing].
Okay, we figured this out by now: The 'mdadm' hook does not only disable the auto-assembly, it lacks any udev rules in initramfs - this means that udev will not know about file system type on the RAID contents and LVM auto-assembly fails. The solution would be to include the udev rules in the mdadm hook as well, and just disable auto-assembly. On another note: The mdadm_udev behaviour used to be the default for a while, but we had a lot of whining about it - none of the affected people had any interest in figuring out why auto-assembly failed for them. I'd really like to get rid of the non-udev based mdadm assembly, so if anyone has an idea why there were problems, feel free to share. While we're at it, I'd like to fix mdadm's udev rule to use BUILTIN+="blkid" instead of manually calling blkid.
On Sun, Nov 04, 2012 at 05:07:59PM +0100, Thomas Bächler wrote:
Am 03.11.2012 02:40, schrieb Eric Bélanger:
If you use both RAID and LVM, make sure that you use the mdadm_udev hook instead of the mdadm one. I had to do this change to make my system boot with the lvm2 package in [testing].
Okay, we figured this out by now:
The 'mdadm' hook does not only disable the auto-assembly, it lacks any udev rules in initramfs - this means that udev will not know about file system type on the RAID contents and LVM auto-assembly fails.
I guess I knew this, as it caused problems in the past when we created mdadm_udev: https://bugs.archlinux.org/task/28067
The solution would be to include the udev rules in the mdadm hook as well, and just disable auto-assembly.
This was always the sticking point -- is there a way to disable auto assembly but keep the rule file as is? I'd rather we didn't duplicate it.
On another note: The mdadm_udev behaviour used to be the default for a while, but we had a lot of whining about it - none of the affected people had any interest in figuring out why auto-assembly failed for them. I'd really like to get rid of the non-udev based mdadm assembly, so if anyone has an idea why there were problems, feel free to share.
While we're at it, I'd like to fix mdadm's udev rule to use BUILTIN+="blkid" instead of manually calling blkid.
This is definitely needed. I think the -o udev output from blkid is going away in u-l 2.23. The blkid builtin is already almost a year old -- would make more sense to just convince upstream to make the change. d
Am 04.11.2012 17:19, schrieb Dave Reisner:
The solution would be to include the udev rules in the mdadm hook as well, and just disable auto-assembly.
This was always the sticking point -- is there a way to disable auto assembly but keep the rule file as is? I'd rather we didn't duplicate it.
There is, and it is incredibly stupid: The non-udev mdadm hook includes 'mdassemble' and not 'mdadm', and the udev rule uses 'mdadm'. If we add the udev rule to the hook as it is, we're fine. Or we symlink mdadm to true.
While we're at it, I'd like to fix mdadm's udev rule to use BUILTIN+="blkid" instead of manually calling blkid.
This is definitely needed. I think the -o udev output from blkid is going away in u-l 2.23. The blkid builtin is already almost a year old -- would make more sense to just convince upstream to make the change.
Yes, we should report it to them, but we should also patch our version of the rule.
On Sun, Nov 04, 2012 at 05:25:22PM +0100, Thomas Bächler wrote:
Am 04.11.2012 17:19, schrieb Dave Reisner:
The solution would be to include the udev rules in the mdadm hook as well, and just disable auto-assembly.
This was always the sticking point -- is there a way to disable auto assembly but keep the rule file as is? I'd rather we didn't duplicate it.
There is, and it is incredibly stupid: The non-udev mdadm hook includes 'mdassemble' and not 'mdadm', and the udev rule uses 'mdadm'. If we add the udev rule to the hook as it is, we're fine. Or we symlink mdadm to true.
Yeah that's pretty stupid =P. You'll miss out on some metadata being added to the device nodes in the udev DB by doing this.. things like: MD_LEVEL=raid0 MD_DEVICES=2 MD_METADATA=1.2 MD_UUID=edf34247:6a46d6e6:0b209b2c:a9b29539 MD_DEVNAME=0 MD_NAME=archiso:0 Though, I suppose this will just get added when udevadm trigger is called later in userspace proper.
While we're at it, I'd like to fix mdadm's udev rule to use BUILTIN+="blkid" instead of manually calling blkid.
This is definitely needed. I think the -o udev output from blkid is going away in u-l 2.23. The blkid builtin is already almost a year old -- would make more sense to just convince upstream to make the change.
Yes, we should report it to them, but we should also patch our version of the rule.
The rule is showing signs of age elsewhere too -- things like $tempnode should be replaced with $devnode instead (the former is a relic of pre-devtmpfs). d
participants (4)
-
Dave Reisner
-
Eric Bélanger
-
Lukas Jirkovsky
-
Thomas Bächler