#8313 NORM 9.1.0: Can OFW save-nand be made to go faster?

[Zarro Boogs per Child]

#8313: Can OFW save-nand be made to go faster?
-----------------------------------+----------------------------------------
   Reporter:  thomaswamm           |       Owner:  wmb at firmworks.com                
       Type:  enhancement          |      Status:  new                              
   Priority:  normal               |   Milestone:  9.1.0                            
  Component:  ofw - open firmware  |     Version:  Development build as of this date
 Resolution:                       |    Keywords:                                   
Next_action:  test in release      |    Verified:  0                                
  Blockedby:                       |    Blocking:                                   
-----------------------------------+----------------------------------------

Comment(by wmb at firmworks.com):

 Replying to [comment:14 thomaswamm]:

 > Incidentally, I learn from this that backup/restore via save-nand/copy-
 nand does not restore the XO 'exactly', since scan-nand shows different
 results before and after.  Before backup, the nand is very fragmented.
 After restore, the nand is unfragmented.

 It would not be possible to restore "exactly" in the general case, because
 the machine on which you are restoring might have bad blocks in different
 locations than the machine where you did the save.

 JFFS2 doesn't care which block contains a given bit of data, so you can
 rearrange the blocks arbitrarily without any problems.

 The reason for the "fragmentation", which is not really fragmentation in
 the usual sense, is because JFFS2 randomized the write locations to
 prevent premature "wear out" of individual NAND FLASH blocks.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8313#comment:15>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system