#3978 BLOC Trial-3: Journal getting blank

[Zarro Boogs per Child]

#3978: Journal getting blank
------------------------+---------------------------------------------------
  Reporter:  amitgogna  |       Owner:  dwmw2                            
      Type:  defect     |      Status:  new                              
  Priority:  blocker    |   Milestone:  Trial-3                          
 Component:  kernel     |     Version:  Development build as of this date
Resolution:             |    Keywords:  Journal Blank Out                
  Verified:  0          |  
------------------------+---------------------------------------------------

Comment(by dwmw2):

 Replying to [comment:33 tomeu]:
 > Replying to [comment:31 dwmw2]:
 >
 > One more thing: on those machines where the jffs2 gc thread uses all the
 cpu for 25 seconds, rebooting after the thread has returned to sleep won't
 make that issue go away.
 >
 > After rebooting the gc thread will get busy for the same amount of time.
 I thought that once the thread has finished gc'ing, the next boot would be
 faster. Is that right?

 When the GC thread runs after boot, it's not actually performing garbage
 collection. It's just finishing the mount process, by checking the CRC on
 all data nodes and building the full 'fragment tree' for each file so that
 we know for sure which nodes are valid, and which are obsolete. Once upon
 a time we used to do this _during_ the mount, and the mount itself was
 much slower -- but we realised we could defer it and do it in the
 background after mounting, while read-only operation (and even writes, if
 there's enough actually free space) can continue before it's finished.

 On NAND flash, it's not possible to 'scribble' on obsolete nodes as it
 used to be on NOR flash. So when we first open a file, we have to consider
 each of the old nodes. Once the file has been opened once (by actual
 userspace activity or by the GC thread touching it in its scan after
 mount), we'll _remember_ that most of the nodes are obsolete -- and the
 _next_ time the file is opened it'll be a lot quicker.

 One of the options for improving JFFS2 behaviour in this situation is to
 make it more aggressive about garbage-collecting the eraseblocks
 containing the offending obsolete nodes. Currently, we tend to pick
 eraseblocks with the most obsolete space -- but perhaps the _number_ of
 nodes in the eraseblock should also be a criterion.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3978#comment:34>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system