Re: struct statvfs and larger than 32bit numbers in specific members.
Hi Matt,
Thanks for your input and appologiies for taking the thread off-list.
Does anyone on this list have anything to say about whether or not this
issue should be regarded as a bug? And should be reported as such?
Should i do that?
thanks,
arjen
On Wed, Apr 29, 2015 at 9:17 PM, Matt Bauer m...@ciderapps.com wrote:
I believe you are right but I’m not 100% on it.
Matt Bauer
On Apr 29, 2015, at 7:01 AM, arri arritjeparretje...@gmail.com wrote:
Hi Matt,
Thanks for your helpful reply! I escpecially love the phrasing appropriately
incorrect.
But so if i understand you correctly, my only conclusion then should be
that in this case i should avoid using struct statvfs, and i should instead
be using struct statfs, right?
This would require changes in fuse-core, so i'm going to have to see
whether this is something i can do myself by submitting a patch, or that
the developers should take care of.
Anyway, thanks again for your input!
Kind regards,
Arjen Keesmaat
On Tue, Apr 28, 2015 at 7:36 PM, Matt Bauer m...@ciderapps.com wrote:
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
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
Re: struct statvfs and larger than 32bit numbers in specific members.
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
