[Trac #235] OFW doesn't boot nandflash correctly.
Zarro Boogs per Child
bugtracker at laptop.org
Tue Oct 31 22:10:52 EST 2006
#235: OFW doesn't boot nandflash correctly.
-----------------------+----------------------------------------------------
Reporter: cjb | Owner: wmb at firmworks.com
Type: defect | Status: closed
Priority: blocker | Milestone: BTest-1
Component: linuxbios | Resolution: fixed
Keywords: |
-----------------------+----------------------------------------------------
Changes (by jg):
* status: reopened => closed
* resolution: => fixed
Comment:
Start with a jffs2 image from build 131. Mount it under OFW, scanning the
summary and loading abbreviated versions of all the summary nodes into
memory. The data summary nodes take up about 1.4 MiB (87K data summary
nodes at 16 bytes per). (JFFS2 calls them inodes, but that name gives the
wrong idea if you think of conventional Unix inodes).
Now leave Linux running for a couple of hours or so, with the mouse
unplugged so X keeps bouncing up and down.
Shut down the system cleanly, reboot, and mount it under OFW again.
Now the data summary nodes take up 8 MB. Yes, Virginia, the data summary
area has grown by a factor of 5.7 *while the system is basically not being
used*.
Where is it all coming from?
For starters, there are 2547 junk entries in /tmp, mostly of the form:
.X0-lock .tX0-lock sh-thd-1149890225 (lots of different values for
this number)
But that doesn't explain the data node explosion, because those /tmp
things are mostly directory entry nodes.
Another hotspot is /var/log, which contains 768 entries, nearly all copies
of
Xorg.0.log Xorg.0.log.old
That is the directory nodes. Let's look at the data nodes for a typical
copy of Xorg.0.log. Here's one with inum=5ce2. Oh look, there are 1036
separate data nodes for that log file. I'll bet it makes a separate node
for every line that is appended. ... Yep, that's what is in the nodes, one
line per node. And there are over 200 superseded copies of that file in
/var/log
If we poke around in the summary node array we see that the last 6+ MiB is
mostly just copies of /var/log/Xorg.0.log .
Trac #65 has the other side of the coin: we should not have log files in
flash.
And Trac #248 should be resolved, as right now, this pathological case is
using too much of our RAM.
OFW has been fixed to handle this pathological case, anyway.
--
Ticket URL: <http://dev.laptop.org/ticket/235#comment:4>
One Laptop Per Child <http://laptop.org/>
More information about the Bugs
mailing list