[Server-devel] "Raspbian reserves 4% of all disk space"

[Adam Holt]

...for exactly what is unclear, on headless RPi's in remote areas
especially.  Does someone know more about how this reserve disk threshold
works?  Can it possibly help an untrained operator, in a highly offline
community, when SD-card-as-primary-disk hits that threshold?

Certainly WordPress, X Windows (and no doubt others) silently fail upon
reaching this threshold, rendering the entire system useless, from the
perspective of a low-skill owner-operator (as is the most common case in
the developing world).

So huge thanks to Tim Moody (with George Hunt's assistance) who changed
this threshold from 4% to 1% as follows:

   tune2fs -m 1 /dev/mmcblk0p2

As can be viewed with the "du" (disk usage) command.  The challenge is that
SD-based digital libraries are Almost Always nearly full, by design, when
remote educators ask (and deserve) all the best possible materials.  Nor do
we want to discourage constructionist activities that will occasionally
gobble up a bit of SD/disk!

So More Generally: how exactly might this 4% threshold (pick your favorite
percentage, no matter) materially help remote owner-operators, not steeped
in Linux Skillz?  As so many things start failing together when Raspbian SD
card "disks" reach that reserve threshold — such that most remote/offline
educators and owner-operators will simply stop using their RPi3 digital
library at that point — particularly if it's headless :(

Suggestions from anyone?!

*In principle a http://en.wikipedia.org/wiki/Distant_Early_Warning_Line
<http://en.wikipedia.org/wiki/Distant_Early_Warning_Line> saves lives, but
if Raspbian/Internet-in-a-Box/Etc do not have a GUI-or-similar alert to
signal approaching disk-full danger & facilitate the needed "disk" cleanup,
is this counterproductive, worst case perhaps creating a false sense of
security among implementers?*

*(If so wasting impoverished citizens' prescious SD card funds to no
benefit, or worse giving them a false sense security around RPi reliability
alongside implementers?)*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20170819/95d0030c/attachment-0001.html>