Date: Thu, 4 Sep 2014 09:29:24 -0700 From: Benno Rice <benno@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r271085 - head/lib/libgeom Message-ID: <10BDD3FC-EED9-4A47-BAF4-8F3C2925A3E3@FreeBSD.org> In-Reply-To: <3000146.5OWvozVApa@ralph.baldwin.cx> References: <201409040331.s843Vn5c048905@svn.freebsd.org> <3000146.5OWvozVApa@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 4, 2014, at 6:51 AM, John Baldwin <jhb@freebsd.org> wrote: > On Thursday, September 04, 2014 03:31:49 AM Benno Rice wrote: >> Author: benno >> Date: Thu Sep 4 03:31:48 2014 >> New Revision: 271085 >> URL: http://svnweb.freebsd.org/changeset/base/271085 >>=20 >> Log: >> Systems with lots of geom providers can end up with a = kern.geom.confxml >> value too large for the buffer allocated. Work around this by = retrying >> a few times with larger buffer sizes. >=20 > Are these systems having lots of changes to the GEOM tree while the = sysctl=20 > handler is being invoked? If the tree is static, the first call with = an old=20 > of NULL should return the correct length in 'l' regardless of the size = as it=20 > generates the entire buffer and SYSCTL_OUT's it. (It doesn't do it = piecemeal=20 > and fail on ENOMEM part way through the way some other broken sysctl = handlers=20 > do.) These systems have a lot of drives in them and around the time when = we=92re trying to enumerate there can be lots of activity. In the case = where the tree hasn=92t changed we=92re not doing that much extra work = here and it saves us having to retry everything that happens around the = geom_getxml calls inside libgeom when the tree does change.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10BDD3FC-EED9-4A47-BAF4-8F3C2925A3E3>