On 6/25/07, Christopher Blizzard <[EMAIL PROTECTED]> wrote: > That's going to be interesting, yeah. You would need to teach the > wireless firmware about it? How about just checking on wakeup? Some > kind of wake-on-lan signal?
Binding upgrade notifications to a multicast address as I previously proposed fixes this problem without any kind of firmware hacking. > Can you explain how they are odd? It sure would help everyone. Caveat: I'm not an expert here. I haven't read the code, just the documentation. So we can all follow along, start here: http://linux-vserver.org/Paper#Unification http://linux-vserver.org/Frequently_Asked_Questions#What_is_vhashify.3F Basically, copy-on-write works by running a tool ('vhashify') which looks for identical files in the different containers and hard links them together, then marks them immutable. The copy-on-write mechanism works by intercepting writes to immutable files and cloning the file before making it writable by the container. Quoting from their FAQ: (when running vhashify:) "The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via vserver enter. In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers." Since vserver is doing file hashification anyway, it seems like it would be a much better idea to use this rather than reinvent the wheel. Some other issues: a) we may need to be aware of which files are hardlinked where in order to do proper updates. b) not clear how/if we can make updates to an entire tree atomically c) how/can we restart the vservers? how important is this? I think we need to bring in a vserver expert (ie, not me) to get these details right at the start. > Yeah, but you always need both sets of information to be able to > generate them. So you have to host full file + diff data if you want to > host an update. My proposal would be that XOs pass around binary diffs *only* among themselves, and that if someone needs an older version or to leapfrog versions, they ask the school server. This allows XOs to cheaply host updates in the common case. > The nice thing about Alex's system is that you only > have to host the file data that you're using on your system instead of > file + diff data. You end up using less space that way. If you look at the numbers I just posted, file+diff is 1.3% larger than just files. > If you want to > downgrade, you have to get the files or use the vserver versions (maybe > you could just use the old files handled by the CoW stuff to drive the > update system - that might work pretty well!) Now we're talking! ;-) > Keep in mind that those "blobs" he's talking about are just files. The > only place where we would add binary diffs would be for individual > files, not entire trees. So what we're downloading today is only the > changed files, largely for the sake of expediency and what I describe > above for the space savings. I have some issues with the fact that the manifest includes the entire tree as well. Upgrades should only include entries *changed* in the manifest. > But if I have to choose > between having something that works today with full files and saves some > space[...] We're only talking about a week's worth of work here so far. I agree that our schedule is aggressive, so let's get this right at design time, rather than trying to fix things after implementation. --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
