On Sun, 2007-06-24 at 13:24 -0400, C. Scott Ananian wrote: > On 6/24/07, Ivan Krstić <[EMAIL PROTECTED]> wrote: > > I should have a concrete spec ready for discussion later today. > > I will wait with bated breath. =) > > Some concrete concerns -- I've got some answers to these, but I'll try > to just present the questions at this point: > a) Robustness -- what can break our upgrade mechanism? Do we have a > fallback? What dependencies does the upgrade mechanism have? > b) Current vserver code requires restarting the containers when > files inside the container are modified by the root context. There is > also a relinking process necessary. Have we thought through these > interactions?
I haven't really seen a viable way to use vserver for updating the root filesystem. Is there a proposal for how this would work? I had a different idea to do a very robust root filesystem update. Given the layout and format of jffs2 (the filesystem we're using) it is very easy to add filessystem transaction support. That is, we'd have a way to trigger a transaction at the start of an update, then we just do all the changes we want (including just updating the kernel image file). Then when the update is done, we commit the transaction. If at any time we lose power or anything like that, none of the changes after the transaction start will be visible on the next boot. And also, if we have any problems during update (e.g. out of flash) we an rollback and abort. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
