> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Tuesday, September 15, 2020 12:16 PM
>
>> 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?

> Calling stat() on two pathnames and checking whether the device numbers
> are equal (st_dev), you can check whether those pathnames are on the
> same file system.

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.

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

> - Unix tends to reserve n% of each file system's space for the root user
> only. The "Avail" column in `df` output reflects the space available for
> use by normal plebs I think; if you compute Size-Used you may get more
> than that, because root can use more than that. Does statvfs() give the
> space free for root or for plebs?

As John noted, both, and we're using the one "for plebs", 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.

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.

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.

- Harold