I don’t think you’re doing anything wrong nor is OS X. statvfs is defined by a standard. From man statvfs:
The statvfs() and fstatvfs() functions conform to IEEE Std 1003.1-2001 (``POSIX.1''). As standardized, portable applications cannot depend on these functions returning any valid information at all. This implementation attempts to provide as much useful information as is provided by the underlying file system, subject to the limitations of the specified data types. If you look at the published standard [1], it notes that: The implementation shall support one or more programming environments in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t, and useconds_t are no greater than the width of type long. The result is everything is working appropriately incorrect I think. [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html#tag_13_67 <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html#tag_13_67> Matt Bauer > On Apr 28, 2015, at 12:15 PM, arri <[email protected]> wrote: > > Hi, > > I'm using the Fuse (File System in Userspace) to run my own filesystem that i > use to alter the way a shared-storage cluster (SMB-share) is presented on > client-machines, and to create mountpoints of sub-directories of this shared > storage. > > However, i lately ran into the 32bit limits of certain member of struct > statvfs. > The implementation of statfs in Fuse on Mac takes a struct statvfs as a > parameter, to fill-in with the relevant data. However, the actual values for > some of the fields far exceeds the 32bit boundary, as you can see below. > > statfs() does actually report correct values, but statvfs() produces all > kinds of weird numbers. > > Is this an bug in Mac OSX's VFS implementation? > Or is this perfect proof of my lacking knowledge with regard > > Here's the output of both statfs() and statvfs() when ran on the mounted > storage-cluster. > > $ > ./stattest /Volumes/ifs > > Successful statfs-ed and statvfs-ed the filesystem! > > statvfs: > > Fundamental file system block size (f_frsize): 16000 > File system block size (f_bsize): 1048576 > Blocks on FS in units of f_frsize (f_blocks): 29543152 > Free blocks (f_bfree): 3750327544 > Blocks available to non-root (f_bavail): 3750327544 > Total inodes (f_files): 4294967295 > Free inodes (f_ffree): 4294967295 > Free inodes for non-root (f_favail): 4294967295 > Filesystem ID (f_fsid): 805306410 > Bit mask of values (f_flag): 0x00000002 > Max file name length (f_namemax): 255 > > > statfs: > > block-size (bsize): 16000 > io-size (iosize): 1048576 > total block-count (blocks): 8619477744 > free blocks (bfree): 8045294840 > blocks available for non-root users (bavail): 8045294840 > total nr. of file nodes (files): 18446744073709551615 > free file-nodes (ffree): 18446744073709551615 > filesystem id (fsid): { 805306410, 24 } > mounted by (owner): 501 > filesysyem type (type): 0x00000018 > filesysyem subtype (fssubtype): 0x00000004 > flags (flags): 0x00000018 > fs-type name: smbfs > mountpoint name: /Volumes/ifs > mounted filesystem: //[email protected]/ifs > done! > > $ > > > The problem is with these members: f_bfree, f_blocks, f_bavail, f_files, > f_ffree, f_favail which are defined as fsblkcnt_t (__darwin_fsblkcnt_t) and > fsfilcnt_t (__darwin_fsfilcnt_t), both of which are unsigned int's. > > > Is this by design? And how to work around this? Or is the cluster actually > returning bogo-numbers? Or is it yet something else? > > > Kind regards, > > arri > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Filesystem-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/filesystem-dev/matt%40ciderapps.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to [email protected]
