NANDblaster design notes for XO-1.5

[Mitch Bradley]

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, pgf at laptop.org
>