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