#10316 NORM Not Tri: XO-1 "Journal Full" - did 'olpc-update' take too much room in jffs2 ?

[Zarro Boogs per Child]

#10316: XO-1 "Journal Full" - did 'olpc-update' take too much room in jffs2 ?
------------------------------------+---------------------------------------
           Reporter:  mikus         |       Owner:                                   
               Type:  defect        |      Status:  new                              
           Priority:  normal        |   Milestone:  Not Triaged                      
          Component:  not assigned  |     Version:  Development build as of this date
         Resolution:                |    Keywords:                                   
        Next_action:  never set     |    Verified:  0                                
Deployment_affected:                |   Blockedby:                                   
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by mikus):

 Replying to [comment:1 Quozl]:
 > Please check the [ ... Known Problems] section of the release notes,
 > in particular the linked item that describes [ ... Purging_a_previous_OS
 how to remove the old build].  Doing this as part of your customisation
 may avoid the problem.

 In my mind there is a disconnect here within what is being offered to an
 XO user:  On the one hand, there is the 'olpc-update' automatic process,
 which saves the user (when upgrading the OS) from the bother of having to
 explicitly preserve his own work.  On the other hand, there is the
 description you cited, which directs the user to a somewhat bothersome
 manual process (in case the user needs to recover space consumed by
 performing 'olpc-update').

 I thought the developers' intent was, when in the updated build a module
 is unchanged from the previous build, to have 'olpc-update' "link" a
 single copy of that module into the "resident images" kept for both builds
 -- then "purging" the previous build would mainly serve to recover the
 space taken by modules now obsoleted (since unchanged modules would not
 have replacements).

 For me, performing 'olpc-update' (between adjacent builds in a Release
 Candidate series) appears to have consumed more than 300 MB of jffs2
 space.  I had not expected THAT much difference in content between the
 previous build and the updated build.

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