On Tue, 2007-06-26 at 13:55 -0400, Ivan Krstić wrote: > Software updates on the One Laptop per Child's XO laptop > ========================================================
First some stray comments: > 1.4. Design note: rsync scalability > ----------------------------------- > > rsync is a known CPU hog on the server side. It would be absolutely > infeasible to support a very large number of users from a single rsync > server. This is far less of a problem in our scenario for three reasons: What about CPU hogging on the school server? That seems likely to be far less beefy than the centralized server. > The most up-to-date bundle for each activity in the set is accessed, and > the first several kilobytes downloaded. Since bundles are simple ZIP > files, the downloaded data will contain the ZIP file index which stores > byte offsets for the constituent compressed files. The updater then > locates the bundle manifest in each index and makes a HTTP request with > the respective byte range to each bundle origin. At the end of this > process, the updater has cheaply obtained a set of manifests of the > files in all available activity updates. Zip files have the file index at the end of the file. Now for comments on the general approach: First of all, there seems to be exceptional amounts of confusion as to exactly how some form of atomic updating of the system will happen. Some people talk about overlays, others about vserver, I myself has thrown in the filesystem transaction idea. I must say this area seems very uncertain, and I worry that this will result in the implementation of none of these options... But anyway, the exact way these updates are applied is quite orthogonal to how you download the bits required for the update, or how to discover new updates. So far I've been mainly working on this part in order to avoid blocking on the confusion I mentioned above. As to using rsync for the file transfers. This seems worse than the trivial manifest + sha1-named files on http approach I've been working on, especially with the optional usage of bsdiff I just commited. We already know (have to know in fact, so we can strongly verify them) the contents on both the laptop and the target image. To drop all this knowledge and have rsync reconstruct it at runtime seems both a waste and a possible performance problem (e.g. cpu and memory overload on the school server, and rsync re-hashing files on the laptop using up battery). You talk about the time it takes to implement another approach, but its really quite simple, and I have most of it done already. The only hard part is the atomic applying of the bits. Also, there seems to be development needed for the rsync approach too, as there is e.g. no support for xattrs in the current protocol. I've got the code for discovering local instances of updgrades and downloading it already working. I'll try to make it do an actual (non-atomic, unsafe) upgrade of a XO this week. I have a general question on how this vserver/overlay/whatever system is supposed to handle system files that are not part of the system image, but still exist in the root file system. For instance, take /var/log/messages or /dev/log? Where are they stored? Are they mixed in with the other system files? If so, then rolling back to an older version will give you e.g. your old log files back. Also, that could be complicating the usage of rsync. If you use --delete then it would delete these files (as they are not on the server). Also, your document contains a lot of comments about what will be in FRS and not. Does this mean you're working on actually developing this system for FRS? _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
