For review: NAND out of space patch.

[pgf at laptop.org]

chris wrote:
 > Hi,
 > 
 >    > I'll go on record repeating the comments made earlier. deleting the
 >    > students largest file is probably deleting their most important
 >    > work.
 > 
 > Of course, it should be only a last resort; I tried to make that clear.
 > I hope that in 8.2 we'll fix the problem in general, in a way that
 > prompts for which files to delete.  This patch would be an interim
 > workaround for deployments to ameliorate the current problem of
 > non-booting laptops, and a failsafe for any edgecases we miss in 8.2.

it sure feels as if adding a time component to the "nuking"
algorithm would help (e.g. something based on "du -s $(ls -rtd PATH/*)"),
but i guess it wouldn't, really.  can we at least nuke some
obvious big (or otherwise useless-in-a-deployment) installed
files first?  that's only a one-time thing, but it's arguably
better than losing "real" data.

ben wrote:
 > This hackish approach is meant only as a patch to existing systems running
 > old builds.  Uruguay has a comprehensive system for deploying such patches
 > quickly.  Based on our new understanding of the urgency of the full NAND

is it really true that uruguay can deploy patches quickly?  then
surely we can come up with a simple cron-based script that puts a
large-font warning in an xterm when diskspace is low?  it would
(obviously) be ugly, but still better than a failed boot and loss
of data.  if the diskspace disappears all at once, due to downloads
or something, then this won't help, but i'll bet we could choose
a threshold that would be successful pretty often.  we might even
cause it to run more often when browse or record is running.

paul
=---------------------
 paul fox, pgf at laptop.org