#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:3 Quozl]:
 > Since you customise after install, every file you change in the
 filesystem that olpc-update wants to repair will cost toward that 300 MB
 kept in the previous build tree.
 What you are pointing out here is that 'olpc-update' lets stand all
 changes __I've__ made to the content of the previous build.  [If I earlier
 applied an RPM to the previous build, and I now apply that same RPM to the
 updated build - I end up with two copies of that RPM's content in jffs2
 (until that previous build, with all associated content, gets deleted).]

 Why would 'olpc-update' think it needed to repair 300 MB of files?  On
 another XO-1 system with 'copy-nand' install of 851, 'du' for
 /versions/pristine shows 897 MB, while 'du' for /versions/run shows 1054
 MB - that's at most 157 MB of system changes applied after the initial
 install.  [All my systems receive the same customization.]  This "starting
 point" has the /versions/pristine tree:

 ||''851''||''852''||''disk free space''||
 ||897 MB||not present||431 MB||

  [[BR]]
 In my case, os851 was installed on the XO-1, olpc-update to os852 was
 done, and the /versions/pristine/ trees for each build showed up with the
 following sizes:

 ||''851''||''852''||''disk free space''||
 ||905 MB||310 MB||84 MB||

 Also, the /versions/run trees for each build showed up with the following
 sizes:

 ||''851''||''852''||
 ||1074 MB||592 MB||

 After removing /versions/pristine/851 and /versions/run/851 the
 /versions/pristine tree was:

 ||''851''||''852''||''disk free space''||
 ||not present||898 MB||425 MB||

 ----

 I'm not questioning whether the combination of __simple__ 'olpc-update'
 plus __manual__ 'rm -rf /versions/.../previous_build' is an effective way
 to update the OS.  What I am questioning is why, without notice, 'olpc-
 update' can leave the system in a state where unexpected warnings appear.
 [And where the user has to do some serious reading of wiki pages to find
 out what to do now.]

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