Instead of adding a scale factor to the Host Resources MIB, which would
be incompatible with the current MIB as you point out, how about just adding
a new object (to the same or a new group) that is the high order 31 bits of a
62-bit quantity? So the current object would continue to be the low order 31
bits and the new object would be the high order 31 bits. Then it would be
compatible with current implementations, until a storage device actually
exceeded 2**31 bits.
Tom Hastings, Printer Working Group (PWG)
P.S. The Printer MIB - RFC 1759 uses the Host Resources MIB. The PWG is
anxious for the Host Resources MIB to be updated, because we have a small
number of requirements that we'd like to input into that process.
You can reach us at pwg at pwg.org
Thanks,
Tom
At 16:24 09/23/96 PDT, you wrote:
>Attached is a comment/warning from the Host Resources MIB mailing list
>that should be of interest to Printer MIB agent implementors.
>> ...jay
>>----- Begin Included Message -----
>>>From andrew.cmu.edu!sw0l+hostmib-errors Mon Sep 23 19:22:46 1996
>From: "Ulrich Haebel SNI" <haebel at pyramid.com>
>Date: Mon, 23 Sep 1996 15:02:53 -0700
>To: hostmib at andrew.cmu.edu>Subject: hrStorageSize limits
>Mime-Version: 1.0
>>RFC1514 defines the hrStorageSize as SYNTAX INTEGER (0..2147483647).
>The size of file systems may go beyond this range. The statvfs struct on
>SVR4 machines defines the number of blocks on a certain file system as an
>u_long variable. This is larger than the above value. Upcoming 64 bit machines
>will need even larger values of hrStorageSize than 4294967295!
>One way to work around this problem may be to use an artificial value
>for hrStorageAllocationUnits. But then hrStorageAllocationUnits is no
>longer the size of allocated data objects as defined in the MIB definition.
>>Any clue?
>>--
>Ulrich H\"abel haebel at pyramid.com>Pyramid Technology - A Siemens Nixdorf Company (408) 428-8112
>>>----- End Included Message -----
>>