equivalent copy-nand interface ideas for XO-1.5

Deepak Saxena dsaxena at laptop.org
Mon Jun 15 14:51:46 EDT 2009

On Jun 14 2009, at 11:00, Paul Fox was caught saying:
> i won't quote anything you wrote, because i have nothing to
> add to your lists of pros and cons of those methods.

Ditto. +1 on the original proposal.

> another possibility:  size the original fs image to the size of
> the data it will hold:  i.e., create a filesystem with no free
> space.  this will eliminate the sparseness issue when
> distributing.  use OFW to write this in a raw, filesystem-unaware
> manner.  mark the file system in such a way that the initrd will
> know (or perhaps it will simply guess, based on sizing) to resize
> the filesystem before mounting, in order that it fill the
> available space.  my impression is that the extN filesystems are
> fairly easy to grow in place?

EXT2+ can be grown in place. My concerns with this approach are:
It would add more delay to initial post-flash bootup. This
could be trivial and not noticeable so we should measure it. 
More importantly, if we encounter powerfail or some other 
scenario that causes the resize to not complete, we will probably 
end up with an unuseable filesystem. I suppose this is no different
of a concern than powerfail in the middle of OFW updating the system.


More information about the Devel mailing list