Apple

On Apr 29, 2015, at 7:01 AM, arri <email@hidden> 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 <email@hidden> 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 <email@hidden> 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@hidden/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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>struct statvfs and larger than 32bit numbers in specific members. (From: arri <email@hidden>)
	>Re: struct statvfs and larger than 32bit numbers in specific members. (From: Matt Bauer <email@hidden>)

Prev by Date: Re: struct statvfs and larger than 32bit numbers in specific members.
Previous by thread: Re: struct statvfs and larger than 32bit numbers in specific members.
Index(es):
- Date
- Thread