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): 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: //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

Reply via email to