It seems that on every single boot "vgs" is invoked by some init script which then iterates through /dev and stat()s every file in there. That's a bad idea, since we nowadays create automount points for /dev/mqueue and /dev/hugepages and even though vgs doesn't actually needs those they get triggered by it. The effect of this is that the two file systems are always mounted after boot, even though nothing actually really uses them. In general, vgs shouldn't iterate at all through /dev, and use the udev database instead when it is looking for block devices. Iterating through /dev is a recipe to make things slow. The least vgs should be doing is not calling stat() on the files it finds in /dev. It should use lstat() instead, which does not trigger automount actions. Alternatively it should just use the information passed by readdir() in the dirent to userspace. The d_type field of dirent is guaranteed to be valid on /dev these days, since it is backed by tmpfs or devtmpfs. In any case vgs should not traverse to file systems mounted below /dev, to avoid triggering of automounted file systems. It is easy to identify vgs as culprit for triggering the automounts since systemd will log to the kernel log buffer which client process is triggering the automount if you boot with "systemd.log_level=debug" and "systemd.log_target=kmsg".
yes - true - I've also noticed this one - when I use /dev/shm as a temporary ram storage. This will be fixed. We need to use regex blacklisting sooner also for stating dirs in /dev
No, please do not use "regex blacklisting". Use a clean a proper API, use libudev. And do not recursively iterate through /dev. Using "regex blacklisting" is just a bad workaround on top of something that is already ugly.
Couple solutions are under discussion - sometime we decide to provide quick hack to cover the biggest problem and proper solution will takes it's time. The good solution must work for everyone and must not break any previous functionality. One of the evaluated solution is of course the usage of libudev enumeration API.
We have a simple patch that uses libudev to obtain the list of block devices. The patch is under review.
that's good news! thanks!
When we're at it, we're also trying to recognize LVM2 membership based on blkid info exported in udev db which could simplify the filtering of unsuitable devices (mainly in situation when there are many of them in the system). If this proves to be working fine, we'll attach this patch to the original one. Reviewing, testing...
The original patch is upstream now. Though the other filtering optimisation mentioned above is not included yet (but it may be included later, we'll see). The problem reported in this bug report should be resolved. There's a new setting in lvm.conf called 'obtain_device_list_from_udev' to enable or disable this feature (it's enabled by default).
I don't think we'll do a rebase for F15 at this moment, this feature is available on F16+ (lvm2 v2.02.85+). Setting closed/nextrelease.