On Fri, Jul 11, 2008 at 06:33:41PM +0100, Gary C Martin wrote: > > One concern I have with auto saving state before powering off is the > potential corruption of journal data. How robust is the Journal if > power off happens half way through an ongoing auto state save – do you > loose both the new journal entry and the original entry you had > resumed from (partially overwritten)? > > The worst case just now seems to be EToys, it's really great for > tinkering, but creating even simple scripts seems to require a massive > amount of time to save (example 5+min!! to close & save a script with > five polygon space invaders with 2 frames of animation and a few lines > of movement code). Add to that that EToys seems to be almost as power > intensive as video recording (my impression only, I've not power > tested). I find I'm the habit of plugging into mains before I try and > close an EToys instance I've made more than a few modifications to. >
Based on some very provisional testing, I believe that the extremely long save times we're seeing in EToys are at least partly related to our use of zlib compression for data nodes in the filesystem. We could switch to LZO compression for a 500% speedup in compression (write), a 50% speedup in decompression (read), and a slight (but significant) decrease in compression ratio. While working with Record I noticed that we cannot write very high resolution video (>320x240 @ 10fps) to the filesystem because of this issue. It would help to know what other applications are suffering because of poor fs write speed. There is an existing ticket to address this issue (http://dev.laptop.org/ticket/2072). This ticket suggests that we could add LZO support to OFW in order to implement LZO-compressed data nodes in the filesystem. In this scheme OFW would require LZO support to boot a kernel which resides on an LZO-compressed fs. But an alternative is to implement a partitioning scheme in which user data resides on a LZO-compressed partition and the system data resides on a zlib-compressed partition. This would provide us with good compression for system components (saving space) but would also allow users to write data much more quickly. That said, implementing LZO compression across the entire system might improve system responsiveness by a noticeable margin, so it might be worthwhile. Testing is required. Erik _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel