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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
