On Jul 22, 2008, at 2:23 PM, Jim Gettys wrote: > Ah, I like this idea better than the previous I've heard; if we can > uninstall software or cleanup the journal with human intervention, > that > would be good.... I'm nervous about automatic cleanup schemes.... > - Jim
Agreed. Emiliano was already aware of cjb's patch via devel. I haven't recommended it to Uruguay, but I did make sure that Fiorella knew of it as one possible solution for her consideration. wad > On Tue, 2008-07-22 at 13:20 -0400, Erik Garrison wrote: >> On Tue, Jul 22, 2008 at 12:53:37PM -0300, John Watlington wrote: >>> >>> On Jul 22, 2008, at 12:06 PM, Chris Ball wrote: >>> >>>> Hi, >>>> >>>>> Can you walk me through the exact steps that the user would >>>>> experience if this script was installed? >>>> >>>> They wouldn't see anything different, but Journal entries >>>> corresponding >>>> to files we chose to delete wouldn't resume properly. >>>> >>>>> In terms of which files, I think the oldest (or maybe LRU as they >>>>> say in caches) would be better than the largest. Can we do that >>>>> (e.g. delete oldest then iterate until x MBs is free)? >>>> >>>> I disagree; I don't think we're filling up with small Write or >>>> Paint >>>> documents, my intuition is that we're filling up with recent large >>>> downloads and movies. In the case where the problem is a huge >>>> download >>>> the user just made, your scheme results in deleting *everything*. >>>> >>>> Since we disagree, maybe best to wait until we have some disk-full >>>> images back from the field so that we can see what used up all the >>>> space, before deciding the algorithm. >>> >>> I'm getting three images right now. >>> >>> One of the machines booted, but wouldn't allow any activities to >>> launch >>> (which since you can't log in on vttys kinda locks down the >>> machine). >>> But I did notice a large number of non-standard activities (e.g. >>> Doom). >> >> This sounds familiar. I think several teachers from Uruguay have >> mentioned on the Sur list that their students love to download >> software >> and have filled up their storage space. I'll try to find the >> reference. >> I have also heard the same from a contractor in Uruguay who has been >> involved in distribution (via #olpc-ayuda). >> >> Today I am going to test a solution in which we union-mount a >> tmpfs over >> top of a full root filesystem (which is effectively read-only). This >> should allow us to boot, but obviously any changes made to the tmpfs >> during the session will be lost. Provided we can boot in this >> scheme, >> we should immediately open a dialogue which asks the user to select >> Activities to delete. >> >> I think that such a 'recovery-mode' is ultimately the best we're >> going >> to do to help resolve this issue. We must provide students a way to >> manage their systems, and to do so even in a NAND-full state, or the >> solution to NAND-full will continue to be centralized and costly. >> If it >> is not something that we ship immediately to help resolve the >> issue in >> Uruguay, the current situation demonstrates that it is a worthwhile >> target for future releasese. >> >> Erik >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.laptop.org/listinfo/devel > -- > Jim Gettys <[EMAIL PROTECTED]> > One Laptop Per Child > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
