For review: NAND out of space patch.
eben.eliason at gmail.com
Tue Jul 22 18:54:24 EDT 2008
On Tue, Jul 22, 2008 at 6:45 PM, Martin Langhoff <martin.langhoff at gmail.com>
> On Wed, Jul 23, 2008 at 10:38 AM, Eben Eliason <eben.eliason at gmail.com>
> > But, assuming we can actually boot into usable Sugar, we've solved almost
> > half the battle, since the non-modal alert can then strongly encourage
> > user to deal with the issue. It's not the flat out guarantee we need to
> \> this comes down to determining the correct heuristic for removing files,
> If you mean "user files" then the problem is that there is never a
> correct heuristic. Chris and Greg have pointed out valid use cases
> that run afoul of "largest" and "oldest" heuristics. We could tweak it
> but as long as it is user files...
Agreed. I should again clarify that I'd prefer, at least until absolutely
in desperate need of space (or even then?), that we use the heuristic (as
smart as it may be...I have a number of ideas, but this could use a
conference on it's own) to /recommend/ to the user what files could be
removed without their caring so much. It wouldn't go deleting stuff willy
nilly, and the first flag the heuristic should check is whether or not it
has been backup up, and second whether or not it is starred. We might
provide an option to just "delete all" (of those recommended) for users who
trust us, for whatever reason, or don't want to be bothered with the chore.
But, the main point here, is that we can drastically reduce the extent of
the chore of managing (continuously, let's face it) the small amount of
storage space by making such recommendations periodically, before the need
> Erik has outlined a scheme that could get the machine to boot so that
> the user can delete some\thing.
> Deleting safe (cache) files + bind-mounting a tmpfs seem
> complementary. Deleting user files is a wrong that no smarts can make
> right. Specially since ds-backup is not there yet.
> If ds-backup-client is in place, files older than the mtime of
> .sugar/default/ds-backup-done are safe to rm
Right. Safely, but still intelligently, and even then likely only if
absolutely forced to do so. I'm excited about all your hard work on backup,
so we can begin to explore this in the Journal for future releases.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel