On 2020-07-01 17:40, Martijn van Duren wrote:
> On Wed, 2020-07-01 at 10:59 -0400, Johan Huldtgren wrote:
> > hello,
> >
> > On 2017-11-27 10:31, Gerhard Roth wrote:
> > > On Sat, 25 Nov 2017 11:42:07 -0700 Joel Knight <[email protected]>
> > > wrote:
> > > > On Thu, Mar 9, 2017 at 10:02 PM, Joel Knight <[email protected]>
> > > > wrote:
> > > > > Hi.
> > > > >
> > > > > snmpd(8) uses unsigned ints internally to represent the size and used
> > > > > space of a file system. The HOST-RESOURCES-MIB defines the valid
> > > > > values for those OIDs as 0..2147483647. With sufficiently large file
> > > > > systems, this can cause negative numbers to be returned for the size
> > > > > and used space OIDs.
> > > > >
> > > > > .1.3.6.1.2.1.25.2.3.1.5.36=-1573167768
> > > >
> > > > Hi. Just wanted to bump this again and see if anyone that cares about
> > > > snmp could take a look? Looking for oks and someone who wouldn't mind
> > > > committing it.
> > > >
> > > >
> > > > > At sthen's suggestion, do what net-snmp does and fiddle with the
> > > > > values to prevent wrapping. Yes this mucks with the actual values of
> > > > > size, used space, and block size, but it allows snmpd to convey the
> > > > > proper size and used space of the file system which is what most
> > > > > everybody is really interested in.
> > > > >
> > > > > In case gmail hoses this diff, it's also here:
> > > > > https://www.packetmischief.ca/files/patches/snmpd.hrstorage2.diff
> > >
> > > Hi Joel,
> > >
> > > I think this won't work unless you also change the type of 'size' and
> > > 'used' to u_int64_t.
> >
> > I ran into an issue where my snmpd underreported my filesystem size.
> >
> > $ df -h /ftp
> > Filesystem Size Used Avail Capacity Mounted on
> > /dev/sd0a 50.5T 13.7T 34.3T 29% /ftp
> >
> > However snmp reports something different.
> >
> > $ snmp walk -v 2c -c public localhost hrStorage
> >
> > hrStorageDescr.40 = STRING: /ftp
> > hrStorageAllocationUnits.40 = INTEGER: 8192 Bytes
> > hrStorageSize.40 = INTEGER: 2487209520
> >
> > sthen@ pointed me to this thread but suggested 'int_t' as opposed to
> > 'u_int_64_t', making that change and applying it fixes the issue for
> > me.
> >
> > hrStorageDescr.40 = STRING: /ftp
> > hrStorageAllocationUnits.40 = INTEGER: 32768
> > hrStorageUsed.40 = INTEGER: 459624840
> >
> > Updated patch attached.
> >
> > thanks,
> >
> > .jh
>
> Some minor tweaks:
> - Use u_int64_t instead of size_t
> - Put the calculation outside the switch, so memory can profit as well.
>
> OK?
Tested and your updated patch works fine for me.
thanks,
.jh
>
> martijn@
>
> Index: mib.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 mib.c
> --- mib.c 15 May 2020 00:56:03 -0000 1.99
> +++ mib.c 1 Jul 2020 15:39:37 -0000
> @@ -563,7 +563,7 @@ mib_hrstorage(struct oid *oid, struct be
> u_int32_t idx;
> struct statfs *mntbuf, *mnt;
> int mntsize, maxsize;
> - u_int32_t units, size, used, fail = 0;
> + u_int64_t units, size, used, fail = 0;
> const char *descr = NULL;
> int mib[] = { CTL_HW, 0 };
> u_int64_t physmem, realmem;
> @@ -645,6 +645,12 @@ mib_hrstorage(struct oid *oid, struct be
> used = mnt->f_blocks - mnt->f_bfree;
> sop = &so[3];
> break;
> + }
> +
> + while (size > INT32_MAX) {
> + units *= 2;
> + size /= 2;
> + used /= 2;
> }
>
> /* Tables need to prepend the OID on their own */
>
