Date: Thu, 04 Sep 2014 13:49:51 -0400 From: John Baldwin <jhb@freebsd.org> To: Benno Rice <benno@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: <15042946.uzA1DvBfCL@ralph.baldwin.cx> In-Reply-To: <10BDD3FC-EED9-4A47-BAF4-8F3C2925A3E3@FreeBSD.org> References: <201409040331.s843Vn5c048905@svn.freebsd.org> <3000146.5OWvozVApa@ralph.baldwin.cx> <10BDD3FC-EED9-4A47-BAF4-8F3C2925A3E3@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, September 04, 2014 09:29:24 AM Benno Rice wrote: > 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.c= onfxml > >> value too large for the buffer allocated. Work around this by ret= rying > >> a few times with larger buffer sizes. > >=20 > > Are these systems having lots of changes to the GEOM tree while the= sysctl > > handler is being invoked? If the tree is static, the first call wi= th an > > old of NULL should return the correct length in 'l' regardless of t= he > > size as it generates the entire buffer and SYSCTL_OUT's it. (It do= esn't > > do it piecemeal and fail on ENOMEM part way through the way some ot= her > > broken sysctl handlers do.) >=20 > These systems have a lot of drives in them and around the time when w= e=E2=80=99re > trying to enumerate there can be lots of activity. In the case where = the > tree hasn=E2=80=99t changed we=E2=80=99re not doing that much extra w= ork here and it saves > us having to retry everything that happens around the geom_getxml cal= ls > inside libgeom when the tree does change. I more meant that the commit message implied you needed this to handle = a large=20 buffer, but that shouldn't be true. You should only need this to handl= e large=20 changes in the size of the buffer. (I.e. it grows by more than 4k in b= etween=20 the first two sysctl() invocations.) Doubling the size on each iterati= on is=20 one approach (and is fine), another common one is to keep both sysctls = in the=20 loop so you fetch the new size in each iteration, e.g.: buf =3D NULL; for (;;) { sysctl(..., NULL, &len); buf =3D realloc(buf, len); sysctl(..., buf, &len); } --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15042946.uzA1DvBfCL>