Bug 682018 - vgs stat()s every file and directory in /dev on boot
vgs stat()s every file and directory in /dev on boot
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-03-03 17:23 EST by Lennart Poettering
Modified: 2012-03-08 09:03 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-08 09:03:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2011-03-03 17:23:00 EST
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".
Comment 1 Zdenek Kabelac 2011-03-04 07:08:23 EST
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
Comment 2 Lennart Poettering 2011-03-07 15:52:57 EST
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.
Comment 3 Zdenek Kabelac 2011-03-08 04:18:40 EST
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.
Comment 4 Peter Rajnoha 2011-03-21 06:12:01 EDT
We have a simple patch that uses libudev to obtain the list of block devices. The patch is under review.
Comment 5 Lennart Poettering 2011-03-31 07:36:49 EDT
that's good news! thanks!
Comment 6 Peter Rajnoha 2011-03-31 09:33:55 EDT
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...
Comment 7 Peter Rajnoha 2011-04-22 08:26:43 EDT
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).
Comment 8 Peter Rajnoha 2012-03-08 09:03:30 EST
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.

Note You need to log in before you can comment on or make changes to this bug.