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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]/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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/filesystem-dev/matt%40ciderapps.com >>> >>> This email sent to [email protected] >> >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Filesystem-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/filesystem-dev/etamura%40apple.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to [email protected]
