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