On 28.11.2014 14:09, Harald Hoyer wrote: > On 28.11.2014 13:59, Robert Milasan wrote: >> On Fri, 28 Nov 2014 13:51:04 +0100 >> "Tom Gundersen" <t...@jklm.no> wrote: >> >>>> Also the patch changes the logging level of 'maximum number of >>>> children reached' to an error, this should be visible as an error >>>> when the number has been reached. >>> >>> I don't think an error is appropriate here (as nothing actually >>> fails). At most a warning I would say. >>> >>> Cheers, >>> >>> Tom >>> >> >> This is an error, because the behavior makes the system not work >> correctly. >> >> I don't care about a warning that much, but in this case and reference >> bug, we see a bug and/or an error which is causes by the small amount of >> children, or the impossibility of udev daemon to create new >> children/workers, stopping the queue processing until the number of >> children is lower the children_max. >> >> Anyway, please do as you wish as long as it gets fixed. >> > > > This is not true. It only defers the uevent until a worker is available. So > logging it as an error is incorrect. It's a debug message. > > We don't have unlimited resources. You don't do "make -j" with unlimited make > jobs either for a kernel build to get the minimum build time. > > Having 1024 concurrent blkid's running will slow down a machine significantly, > because concurrent I/O over a single path is never good. > > So, what we see is a lot of I/O errors because of timeouts on huge systems, if > the bottleneck is saturated. > > Ideally we would limit the concurrent I/O, but we can't know (in a simple way) > where the bottleneck is. It might be a SAN behind FCoE, or iscsi and the > network is the bottleneck. > > That being said, I don't have a sane solution to satisfy everybody. >
Also interesting: udev workers and the time to bring up 2000 LVM LVs on 2 disks. https://plus.google.com/117537647502636167748/posts/eRJFhjLbpta _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
