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 arritjeparretje...@gmail.com 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): 0x0002
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): 0x0018
filesysyem subtype (fssubtype): 0x0004
flags (flags): 0x0018
fs-type name: smbfs
mountpoint name: /Volumes/ifs
mounted filesystem: //root@isilon1.local/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 (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/matt%40ciderapps.com
This email sent to m...@ciderapps.com
___
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
