svn commit: r271085 - head/lib/libgeom

[John Baldwin]

On Thursday, September 04, 2014 09:29:24 AM Benno Rice wrote:
> On Sep 4, 2014, at 6:51 AM, John Baldwin <jhb at 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
> >> 
> >> 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.
> > 
> > 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 with an
> > old of NULL should return the correct length in 'l' regardless of the
> > size as it generates the entire buffer and SYSCTL_OUT's it.  (It doesn't
> > do it piecemeal and fail on ENOMEM part way through the way some other
> > broken sysctl handlers do.)
> 
> These systems have a lot of drives in them and around the time when we’re
> trying to enumerate there can be lots of activity. In the case where the
> tree hasn’t changed we’re 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.

I more meant that the commit message implied you needed this to handle a large 
buffer, but that shouldn't be true.  You should only need this to handle large 
changes in the size of the buffer.  (I.e. it grows by more than 4k in between 
the first two sysctl() invocations.)  Doubling the size on each iteration is 
one approach (and is fine), another common one is to keep both sysctls in the 
loop so you fetch the new size in each iteration, e.g.:

   buf = NULL;
   for (;;) {
       sysctl(..., NULL, &len);
       buf = realloc(buf, len);
       sysctl(..., buf, &len);
   }


-- 
John Baldwin