Subject: Re: [MIB-DOCTORS] Updating Host Resources MIB

From: Benoit Claise <[email-masked]>
Date: Fri, 21 Mar 2014 09:34:35 +0100

Hi Craig,

Let me include the MIB doctors.

Regards, Benoit
> Hello,
>    I recently had a bug report from JFFNMS around the Host Resources MIB.
> The fix is a simple work-around but it got me looking closer at the
> Host Resources MIB, specifically the Storage table.
>
> The problem is that the used and total block count is a Integer32 which
> means, depending on the block size, we're going to hit the limit of that
> measurement. For a block size of 4096, this limit is 16TB.
>
> The partition table (hrPartitionSize) doesn't help either, as its
> effective block size is 1024 Bytes.
>
> Is there a way of updating RFC 2790 so there is a way of fixing this? I
> suspect it would have to be like the ifTable->ifxTable fix for interface
> counters to use the larger types.  I'm willing to help out but surprised
> its not been fixed already as its a generic problem. That makes me think
> there is a bigger problem around this.
>
> Obviously it won't make, say, net-snmp suddenly work with 16TB disks but
> it would be a start.
>
> If there is already an update a pointer to it would be great.
>
>   - Craig

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Mar 2014 09:51:23 +0100

Hi,

one option around this is to simply report in a different allocation
unit size. Of course, you loose precision but once you hit storage
that is larger than 16 TB, it is probably fine to report allocation in
chunks larger than 4 KB.

/js

On Fri, Mar 21, 2014 at 09:34:35AM +0100, Benoit Claise wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 21 Mar 2014 07:04:04 -0700

Existing practice is to increase hrStorageAllocationUnits to a multiple 
of its base size. Net-snmp already does this. If I remember correctly, 
net-snmp will dynamically figure out an optimal multiple based on the 
size of the disks installed.

I'm not sure if it makes sense to update the RFC for this one issue but 
maybe I should collect a list of bugs and enhancement requests so we can 
see if and when it makes sense to do more work on the HRMIB.

Steve

---

From: Craig Small <[email-masked]>
Date: Mon, 24 Mar 2014 21:05:35 +1100

> that is larger than 16 TB, it is probably fine to report allocation in
That seems a work around rather than a fix but it would do it.

I saw someone saying that net-snmp auto-scales but I cannot see
that in the source code.

var_hstore calls the system call statvfs() and just returns various
fields from the returned struct. The relevant variables are unsigned
longs, though the headers imply signed longs or 31 bits on my system.
There are also things like statfs64().

So,there still is this problem but it just a matter of delaying it for
another day?

 - Craig
-- 
Craig Small (@smallsees)   http://enc.com.au/       csmall at : enc.com.au
Debian GNU/Linux           http://www.debian.org/   csmall at : debian.org
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

---

From: Steve Waldbusser <[email-masked]>
Date: Mon, 24 Mar 2014 22:13:48 -0700

Looks like the auto-scaling was added in NetSNMP 5.7.1:

       - reworked hrStorageTable to support large filesystems. The
	hrStorageAllocationUnits does not report real allocation unit size,
	but some calculated value so hrStorageAllocationUnits *
	hrStorageSize gives real size of the filesystem. This calculation
	happens only when hrStorageSize is too small (32bits) for
	filesystem size, e.g. filesystems larger than 8TB with 4096 bytes
	block size. This calculation can be turned off by
	'realStorageUnits' config option.

Steve