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
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

$ > ./stattest /Volumes/ifs

Successful statfs-ed and statvfs-ed the filesystem!


   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


                              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: //root@isilon1.local/ifs


$ >

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,

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:

This email sent to arch...@mail-archive.com

Reply via email to