[hatari-devel] Re: GemDOS_DFree

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 9.6.2025 15.29, Christian Zietz via Emutos-devel wrote:
> NOTE: I'm moving this discussion over to the Hatari mailing list

Thanks!

> I made a little test program and ran it on GitHub (where one has access 
> to macOS):

You could clear the struct before getting its values, to avoid getting 
bogus values for untouched members.

> The results on macOS are ... interesting:
>
> sizeof(struct statvfs) = 64
> sizeof(f_bfree) = 4
> sizeof(f_bavail) = 4

Hm. On Linux these are 8 bytes.

> statfs() = 0
> f_blocks = 83758080
> f_frsize = 4096
> f_bfree = 11770043
> f_bavail = 11770043
> f_bsize = 4161536

3.97 MiB blocksize seems rather unlikely, especially as that would 
indicate that your disk has 45 TB free.  On Linux I got 4 KiB for both.


> First the members are just 4 bytes (32 bits) long!

Some of them are defined like that:
   struct statvfs {
       unsigned long  f_bsize;    /* Filesystem block size */
       unsigned long  f_frsize;   /* Fragment size */
       fsblkcnt_t     f_blocks;   /* Size of fs in f_frsize units */
       fsblkcnt_t     f_bfree;    /* Number of free blocks */
       fsblkcnt_t     f_bavail;   /* Number of free blocks for
....                                  unprivileged users */


> Then, the total file 
> system size is specified by POSIX to be "f_blocks*f_frsize". But it is 
> not clearly specified, whether the free blocks are given in units of 
> "f_frsize" or "f_bsize".
>
> Hatari uses different units for total and free 
> space: "Total = buf.f_blocks/1024 * buf.f_frsize" and "Free = Free/1024 
> * buf.f_bsize".

As they are blocks, using block size seems logical.

> But with the values above, this calculation gives more 
> free space than total space on macOS!

"f_bsize" you got, does seems rather suspicious.

> If we look into how Apple fills these fields:
> https://github.com/apple-oss-distributions/Libc/ 
> blob/63976b830a836a22649b806fe62e8614fe3e5555/emulated/statvfs.c#L35
> ... "f_bsize" corresponds to "f_iosize", which is the "optimal transfer 
> block size". Thus, I'm not sure if it correct to use "f_bsize" here.

Any idea where the code for statfs() that fills those values is?


> Very confusing. I guess the original post will just have to accept that 
> the values on macOS are rubbish.
>
> In any case, this does not seem to be a regression within Hatari.


	- Eero