Idea Details

Support for very large filesystems

Last activity 11-28-2017 09:32 AM
christianelgass's profile image
02-11-2015 11:10 AM

What is the use case of the new feature?

----------------------------------------

Monitoring and reporting of large disks with more than 8TB of disk space. Additionally the goal is to avoid "Integer overflow/wrap" and wrong (negative) values for the total size of very large file systems.

 

 

Describe the new feature in detail

----------------------------------

The two OIDs "devTblks" and "devFblks" are only of data type Integer32, i.e. the maximum value is 2^31. Assuming a block size of 4096 bytes the maximum size of a file system (which is reported correctly) is 2^31 * 4096 bytes = 8.796.093.022.208 bytes. There is "devFreeSpace" and "devUsedSpace", but the information from these OIDs are not that grainy.

 

 

Describe how you envision this new feature being implemented.

-------------------------------------------------------------

* Add two new OIDs called devTblks64 and devFblks64 using the data type CounterBasedGauge64. After this has been done the OID devBsize can again report the correct value.

* Further add two new OIDs devTfiles64 and devFfiles64 as 64bit representatives of devTfiles and devFfiles.

 

 

What business problem will be solved by adding this new feature?

----------------------------------------------------------------

The reporting of the partition utilization will be more grainy and even larger partitions can be reported.

 

 

Describe the importance and urgency

-----------------------------------

low


Comments

11-28-2017 09:32 AM

another 22 months went by without a response. Product management rating 0/10

01-29-2016 06:02 AM

Adding another OID requires a change on the NMS station b/c it has to check for the new OID, this is right. Changing the meaning of an OID requires the NMS station not only to check for a OID, but also to check which MIB version it is looking at, i.e. to find the version of the SNMP agent and then have a Mapping table SNMP agent version <-> MIB version. I guess this is much more error prone than simply adding a new OID and leaving the old OID untouched.

 

Changing the OIDs in MIB is often done by Checkpoint and I hate it.

01-28-2016 01:24 PM

Adding another OID would also require modification of the MIB. However, adding another OID would also require any polling NMS to look for that other OID instead of the original OID. It could be argued that everything would use the new OID instead of the old. That quickly becomes an argument for just modifying the OID in place.

 

If you used block size to represent the unit of size of the block counter (which is more spirit of the law than letter of the MIB), that wouldn't require a new OID either.

 

I'm just saying that there are several options, some which require work by development on the agent, the mib, and the polling system(s) and some which would only require work on the agent.

01-28-2016 12:45 PM

What is your problem w/ adding another OID? I could just sit in the same table right beside the old OID. Users can that decide, which they want to query. This is far more easy than designing a new MIB.

 

For your pseudo block size you too have to introduce another OID. Unless you want to change the meaning of the existing OID devBsize.

01-28-2016 11:31 AM

Introducing another OID would cause the same problems as redefining the data type for an existing OID, however with the benefit of being backward compatible. With a new OID to contain the bigger number, you'd need to compose a new MIB and recompile it.

 

What's the downside of reporting the pseudo block size? Nothing else uses it and if it did, it would likely be in combination with the total blocks, so that calculation would also have been hampered by the original 32-bit block value.

01-28-2016 08:35 AM

Re-defining the Meaning of an OID, even changing the data type is a bad idea, always. Yes, one could use option 2 and report an pseudo block size. But why not introduce another OID reporting the # of blocks as CounterBasedGauge64. This seems to be the most elegant solution to me.

01-28-2016 08:21 AM

Don't misunderstand, i see that a change needs to be made. I just see two options: 1) change the devBsize to a 64 bit value instead of 32 bit or 2) have the snmp agent report a pseudo block size. Option 1 requires rewriting and recompiling the mib. Option 2 requires only an update to the agent.

01-28-2016 05:19 AM

This is Empire MIB, correct. Yes, in theory one could report a fs having a size of 2^64 Byte ([max value of devBsize] * [max value of devTblks]), but that would require a file system having a block size of 2GB. I think still today it is not very common to assign that huge sizes. Alternatively one could report a wrong block size, but I could imagine that people won't like that step.

 

So we are still back at the point that file systems could have more than 2^32 blocks and system edge is not able to report this situation.

01-25-2016 11:45 AM

I remember this. Does this table not have a block size OID? If it does, nothing needs to change except that the block size needs to be updated in the actual table.

01-25-2016 10:57 AM

Hi all,

 

I am just reviewing our ideas. I am wondering if anyone from product management has looked at this idea yet. We opened it almost a year ago and it still has the status NEW. The customer is polling us and needs some answers.

 

Thank you.

 

Ben

02-11-2015 12:07 PM

Is this for the sysedge mib itself? Isn't there an OID for block size? I ask because I haven't seen the MIB, but I know there is one in the hrStorageMIB; it uses a 32 bit counter for block count and a 32 bit counter for block size, giving a total possible size of 16EB (or 18.4EB depending on who you ask).