Re: struct statvfs and larger than 32bit numbers in specific members.
Re: struct statvfs and larger than 32bit numbers in specific members.
- Subject: Re: struct statvfs and larger than 32bit numbers in specific members.
- From: Eric Tamura <email@hidden>
- Date: Mon, 04 May 2015 12:17:15 -0700
statvfs(2) is behaving properly as per the POSIX specifications. We don’t have any plans to address this. It appears to be a usage issue by 3rd parties to resolve separately.
Eric
> On 30 Apr 2015, at 5:05 AM, arri <email@hidden> wrote:
>
> 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 <email@hidden> wrote:
> I believe you are right but I’m not 100% on it.
>
> Matt Bauer
>
>> 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
>>
>>
>
>
> _______________________________________________
> 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
_______________________________________________
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