Hi Bruce,
Let me bit clarify on ZFS issue.

Lets consider the filesystem "mypool" as the ZFS pool and "/mypool/fs1"
which is filesystem under ZFS.

ZFS considers a "mypool" as a ZFS pool and exports "/mypool" as a
filesystem. You can create filesystems under "/mypool". In this example
I have created a sample filesystem "fs1" under "mypool".

seabis@$ /usr/sfw/bin/snmpget -c public -v 1 testnode hrStorageIndex.18
hrStorageType.18 hrStorageDescr.18 hrStorageAllocationUnits.18
hrStorageSize.18 hrStorageUsed.18
HOST-RESOURCES-MIB::hrStorageIndex.18 = INTEGER: 18
HOST-RESOURCES-MIB::hrStorageType.18 = OID:
HOST-RESOURCES-MIB::hrStorageDescr.18 = STRING: /mypool/fs1
HOST-RESOURCES-MIB::hrStorageAllocationUnits.18 = INTEGER: 512 Bytes
HOST-RESOURCES-MIB::hrStorageSize.18 = INTEGER: 104665253
HOST-RESOURCES-MIB::hrStorageUsed.18 = INTEGER: 1325305

testnode@~# zfs list mypool
mypool 17.2G 49.3G 42.5K /mypool

testnode@~# zfs list mypool/fs1
mypool/fs1 647M 49.3G 647M /mypool/fs1

testnode@~# df -h /mypool/fs1
Filesystem size used avail capacity Mounted on
mypool/fs1 66G 647M 49G 2% /mypool/fs1

HOST-RESROUCES-MIB uses statvfs() syscall to determine the size.

f_frsize; /* fundamental filesystem block
(size if supported) */
f_blocks; /* total # of blocks on file system
in units of f_frsize */

Note ZFS does not return the total blocks available in pool instead it
returns number of block available for this filesystem.

Size_of_Filesystem = hrStorageSize * hrStorageAllocationUnits

/mypool/fs1 = 104665253*512/(1024^3) = 49.908 G
/mypool/fs1 (used) = 1325305*512/(1024^2) = 647.121 M

However if you start monitoring /mypool which is the ZFS pool then above
calculations leads to in-correct results

seabis@$ /usr/sfw/bin/snmpget -c public -v 1 testnode hrStorageIndex.16
hrStorageType.16 hrStorageDescr.16 hrStorageAllocationUnits.16
hrStorageSize.16 hrStorageUsed.16
HOST-RESOURCES-MIB::hrStorageIndex.16 = INTEGER: 16
HOST-RESOURCES-MIB::hrStorageType.16 = OID:
HOST-RESOURCES-MIB::hrStorageDescr.16 = STRING: /mypool
HOST-RESOURCES-MIB::hrStorageAllocationUnits.16 = INTEGER: 512 Bytes
HOST-RESOURCES-MIB::hrStorageSize.16 = INTEGER: 103340033
HOST-RESOURCES-MIB::hrStorageUsed.16 = INTEGER: 85

testnode@~# df -h /mypool
Filesystem size used avail capacity Mounted on
mypool 66G 42K 49G 1% /mypool

testnode@~# zfs list mypool
mypool 17.2G 49.3G 42.5K /mypool

/mypool = 103340033*512/(1024^3) = 49.276 G
/mypool (used) = 85*512/1024 = 42.500 K

In case of "/mypool" it reports used as 42.5K which is the data consumed
by "/mypool" as the filesystem, but actually as ZFS as a pool has
consumed 17.2G. Through statvfs() there is noway report the total size
of pool which is 66G. However traditional utilties like df have been
modified to use libzfs in Solaris to report the total size.

df utility in Solaris uses adjust_total_block()
routine which uses libzfs to determine total pool size.

My query is what should SNMP report for MIB values hrStorageSize &
hrStorageUsed for a ZFS pool ("/mypool") which is a pool aswell as a

For ZFS we can

1) Report the size as 66G which is the storage consumed by ZFS pool as a
2) Report the size as 42.5K which is the storage consumed by ZFS pool as
a filesystem.


Bruce Shaw wrote:
> OK, I found the ZFS 1 Tb bug. I'm cross posting this to sfwvn-discuss
> and net-snmp-coders for the widest possible distribution.
> As you noticed earlier
> (http://groups.google.com/group/maili...s/msg/57a1f8db
> 7387d8a3), it has to do with statvfs.
> If we compile without LARGEFILE support, it (as I suspected) is the
> wrong datatype and it rolls over into negative numbers.
> If we do compile with LARGEFILE support, we run into trouble with
> swapctl. When I google on that problem, I find myself (one of my many
> aliases) complaining about it in vain.
> http://forum.java.sun.com/thread.jsp...446&tstart=450
> I'm not the only having trouble.
> http://lists.kde.org/?l=kde-solaris&...0143028372&w=2
> Looks like the kde folks may have found a workaround,
> http://lists.kde.org/?l=kde-solaris&...5889909715&w=2
> but it looks like all they're doing is faking out the linker. I propose
> pretty much the same thing here
> http://osdir.com/ml/network.net-snmp.../msg00036.html
> Please, please don't tell me I have to rewrite swapctl.
> I don't think it's going to do any good anyway, because we have the
> secondary issue of ZFS not reporting the size correctly due to other
> issues. As you note;
> "The design of ZFS filesystems is such that it doesnot have fixed
> hrStorageAllocationUnits, so the size calculation leads to wrong
> results.
> ZFS has it own routines to get the filesystem stats. "
> However, I haven't been able to find those routines.
> I've been through the source tour here:
> http://www.opensolaris.org/os/community/zfs/source/
> but haven't found any sort of API which would report filesystem stats
> unless I'm missing something really obvious.
> Eric Schrock has noted;
> (http://www.opensolaris.org/jive/thre...30215&tstart=0)
> "See zfs_prop_get() as well as zfs_get_user_props(). Of course, these
> functions are subject to change without notice, but I assume you know
> that already ;-)"
> No, I didn't and I need a stable API.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Net-snmp-coders mailing list