Paul Fox wrote: > mitch wrote: > > http://wiki.laptop.org/go/Nandblaster_for_XO-1.5 records my current > > thoughts about NANDblaster for XO-1.5. Please comment. > > > > i'm a little confused by the concerns re: partitioning. most of > what you're designing is a fast block mirroring protocol. seems > like any notion of blocks being in the right partition would > be fairly external to the design,
That was not the case for the XO-1 NANDblaster, where the need to explicitly remap blocks on the client to avoid bad ones had interactions with partitioning. Perhaps the problem does entirely go away on 1.5, but since I am trying to get from point A to point B, with it being a consideration for point A, I had to at least think about it. Also see the next point... > and the wish that "partitions > could be resized on the fly" seems to be particularly unrelated > to the low-level machinery at the core. > Maybe I should have put that in a "Pie in the Sky Wish List" section. What I would really like is to solve the problem of cloning filesystems onto media that are different in size. Solving the problem for the "wildly different case" would be nice, but for now let's just consider the "a little bit different" case. To make it work now you must guess what is the smallest actual size you will ever see for a "4 GB" device, for example. But a) It is hard to guess that, and b) You then penalize devices that are larger, by wasting blocks A post-processing step to fill the larger device involves not only resizing the filesystem, but also resizing the containing partition. In my fantasy world where computers are easy to use and software "just works", the NANDblaster tool would just "do the right thing" and the user would be immediately happy. No downstream steps to go wrong, no shallow-copy delays that make people thing the machine is dead, ... It turns out that Microsoft has taken a run at this problem in the XP Embedded case, with their System Deployment Image format (http://msdn.microsoft.com/en-us/windowsembedded/standard/aa731382.aspx). The format looks to be reasonably well-designed. Ideally, I would like to do something along those lines. The big problem is that Linux filesystem formats evolve so rapidly that it's hard to keep up. > (i guess i probably wouldn't have said anything if the partition-related > comments had been in a separate section.) > Don't make the mistake of thinking that this is a coherent design document at this stage. Really, it is a stream-of-thought capture with only superficial post-editing. > paul > =--------------------- > paul fox, p...@laptop.org > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel