Re: [hatari-devel] Re: GemDOS_DFree

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Now that I've seen your earlier messages (they were not mailed to me), 
I've looked also into Linux kernel sources.

Not all architectures support f_frsize, and all FSes do not set it, 
which agrees with coreutils code.

However, Linux general code sets it to f_bsize when zero, so I'm not 
sure whether that's old Linux comment, or does it apply to some other OS:
https://github.com/torvalds/linux/blob/master/fs/statfs.c#L67)

Anyway, commited change using f_frsize when it's non-zero and f_bsize 
otherwise, both for total & free.


	- Eero

On 13.6.2025 13.24, Christian Zietz wrote:
> Hello,
> you are still using "f_frsize" for "Total", but (conditionally) "f_bsize" for
> "Free". Why? The /same/ multiplier "f_frsize" always applies to /both /values.
> As I've explained in a few emails already. I feel we're getting nowhere here,
> sorry. (Then again, I don't particularly care if Hatari  on macOS is buggy or not.)
> Regards
> Christian
> *Gesendet: *Donnerstag, 12. Juni 2025 um 23:56
> *Von: *"Eero Tamminen" <oak@xxxxxxxxxxxxxx>
> *An: *"Hatari Development" <hatari-devel@xxxxxxxxxxxxxxxxxxx>
> *Betreff: *[hatari-devel] Re: GemDOS_DFree
> Hi,
>
> On 9.6.2025 15.29, Christian Zietz via Emutos-devel wrote:
> ..
>   > The results on macOS are ... interesting:
>   >
>   > sizeof(struct statvfs) = 64
>   > sizeof(f_bfree) = 4
>   > sizeof(f_bavail) = 4
>   > statfs() = 0
>   > f_blocks = 83758080
>   > f_frsize = 4096
>   > f_bfree = 11770043
>   > f_bavail = 11770043
>   > f_bsize = 4161536
>   >
>   > First the members are just 4 bytes (32 bits) long! 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". But with the values above, this calculation gives more
>   > free space than total space on macOS!
>   >
>   > If we look into how Apple fills these fields:
>   > https://github.com/apple-oss-distributions/Libc/ <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.
>   >
>   > Very confusing. I guess the original post will just have to accept that
>   > the values on macOS are rubbish.
>
> Maybe attached patch would be OK for it?
>
>
> - Eero