NANDblaster design notes for XO-1.5
wmb at laptop.org
Sat Nov 14 12:32:03 EST 2009
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
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 fox, pgf at laptop.org
More information about the Devel