>>> I was writing some flaky tests to see if it's returning true results,
>>> but the more I think of my assumptions, the harder this gets.  For
>>> example, is there any filesystem almost guaranteed to be quiescent
>>> between two calls of it?  /tmp is both iffy and not guaranteed to be a
>>> separate file system, neither is /.  But maybe adding 32 MiB to
>>> whatever is /tmp and checking to see if there's less free space is safe
>>> enough.
>>>
>>> Advice is solicited; I have checked the results by hand with df, Linux
>>> is fine, but either I'm too out of it, or OpenBSD is lying.
>>
>> Good questions.
>
> Let me ask another: is 32 GiB too much, too little, or about right?

Sorry, I don't think I understood the line of reasoning.

Are you writing a unit test to check whether the results are in the same
ballpark if you get the free space multiple times for the same pathname?
And wondering about what size ballpark to use :)

I don't think any file system other than some kind of null mount or a
read-only mount is guaranteed to stay the same size. For that matter,
there probably aren't guaranteed to be any file systems other than /.
Today's Linux mounts tons of different ones; BSDs are more parsimonious.
Does Cygwin synthesize any mountpoint besides /?

> Which we wrap with file-info.  That's a great suggestion for later,
> e.g. see if ... ah ha, I was right!  The size of filesystems IS
> useful.  E.g. if you find a smallish <= 2G / or /boot, you can be
> pretty sure they're isolated file systems.  Going back to Lassi's
> suggestion, see if /usr/local is separate from / and /usr.  On the
> other hand, the only safe place to write a lot of data to is /tmp for
> a bunch of reasons.

Probably most classic use case for st_dev is to recurse a directory
tree, promising not to cross any file system boundaries. For example,
the rsync -x flag which people normally use. In general, I'd assume
backup programs of all stripes will want to check st_dev.

The combination of st_dev and st_ino is the usual way to uniquely
identify files. (It's probably not reliable across reboots.)

>> Other concerns:
>>
>> - Do the results reflect the Unix quota system or not?
>
> I'd seriously doubt it, the struct they return has a lot of very low
> level stuff.  But looking at tune2fs just now, it has a quota thing.

Hmm. The POSIX statvfs specs are silent on quota:

<https://pubs.opengroup.org/onlinepubs/9699919799/functions/statvfs.html>

<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_statvfs.h.html>

Does that mean it's implementation-defined?

> As John noted, both, and we're using the one "for plebs",

That sounds like a good call.

> although
> hopefully they've set, say, ~2% in reserve for their multiple TB
> filesystems.  Pretty sure that's safe without serious fragmentation
> issues for almost everyone except raw video editors and the like.

Yeah, it was useful to reduce it from 5% to 2% back in the day. Running
tunefs() which still won't tune a fish.

> BTW, for now I'm staying with John's "free-space" suggestion, shorter
> names are part of SRFI 170's style, and I think all the stuff missing
> is implicitly very clear.

OK.

> CL's room, though (main memory), sounds like a very nice thing to have.
> Although complicated today by "cache is the new RAM, RAM is the new
> disk, disk is the new tape...."  So I'm not sure what that should do.

CL's room is specified just to display some stuff, not to return any
useful values, so it can take liberties. I guess it's mostly for GC and
allocation stats (how big/slow is my program?) It's copied into a
pre-SRFI: <https://github.com/pre-srfi/interactive-amenities>.