Email list hosting service & mailing list manager

SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 13:39 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? John Cowan (15 Sep 2020 15:56 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Lassi Kortela (15 Sep 2020 16:36 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Lassi Kortela (15 Sep 2020 16:41 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 17:07 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Lassi Kortela (15 Sep 2020 17:16 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? John Cowan (15 Sep 2020 17:17 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 19:02 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Lassi Kortela (15 Sep 2020 19:31 UTC)
A Lisp programmer walks into a room Lassi Kortela (15 Sep 2020 19:42 UTC)
Re: A Lisp programmer walks into a room Arthur A. Gleckler (15 Sep 2020 20:53 UTC)
Re: A Lisp programmer walks into a room Marc Nieper-Wi├čkirchen (15 Sep 2020 20:57 UTC)
Re: A Lisp programmer walks into a room John Cowan (15 Sep 2020 21:11 UTC)
Re: A Lisp programmer walks into a room Lassi Kortela (15 Sep 2020 21:40 UTC)
Re: A Lisp programmer walks into a room Lassi Kortela (15 Sep 2020 21:52 UTC)
Re: A Lisp programmer walks into a room Arthur A. Gleckler (15 Sep 2020 22:15 UTC)
Re: A Lisp programmer walks into a room Lassi Kortela (15 Sep 2020 22:44 UTC)
Re: A Lisp programmer walks into a room hga@xxxxxx (15 Sep 2020 21:54 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 21:27 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Arthur A. Gleckler (15 Sep 2020 22:13 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 22:29 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? Arthur A. Gleckler (15 Sep 2020 22:32 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx (15 Sep 2020 22:40 UTC)
Testing root-only features Lassi Kortela (16 Sep 2020 07:28 UTC)
Re: Testing root-only features Lassi Kortela (16 Sep 2020 07:31 UTC)
Re: Testing root-only features hga@xxxxxx (16 Sep 2020 11:04 UTC)
Re: SRFI 170 file-space -> filesystem-space ?? John Cowan (15 Sep 2020 20:01 UTC)

Re: SRFI 170 file-space -> filesystem-space ?? hga@xxxxxx 15 Sep 2020 19:02 UTC

> 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