Re: JFFS2 issues

["Nancy Isaac" <nancy.isaac@xxxxxxxxx>]

Thanks so much for both of your responses.  My responses are below
with more questions if you can help.

Thanks
Nancy

On 8/6/08, Nancy Isaac <nancy.isaac@xxxxxxxxx> wrote:
> On 8/6/08, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> > On Wed, 2008-08-06 at 10:58 +0200, Hinko Kocevar wrote:


> > > > Summary of my system
> > > > I am working on bringing up a system that's running PPC 8313 with 32MB
> > > > of NOR flash,  512MB of NAND flash and 128MB of RAM.  We have the NOR
> > > > flash to run u-boot and NAND flash has the kernel and file system.
> > >
> > > So NOR is practically empty? All bits, kernel and rootfs plus any
> > > additional partitions, are on NAND then?

Our nor flash has some other stuff like the board id data, some boot
info and we also keep 2 copies of uboot.  But, you are correct, a lot
of it is unused.   We can look at keeing the kernel in NOR.  I've just
never thought of doing that since NAND flash is a bit easier in terms
of updating files during system upgrade.  It doesn't look like the
kernel boot takes much time, most of the time is spent scanning the
flash and mounting partitions.

> > >
> > > > For the NAND flash, we are using JFFS2 for file system type.  I
> > > > initially set up just two partitions, boot and rootfs.  Our root file
> > > > system is about 50MB.
> > >
> > > Big!
> >
> > OLPC mounts 1GiB of NAND flash in about 5 seconds.

Is this using JFFS2?  I must be definetely doing something wrong then.

> > What kernel version are you using, and are do you have summary support
> > enabled?
>

 We are using 2.6.21.  I have the JFFS2 summary option enabled and I
run the sumtool command on the image.

> > Do you have any log files which you're writing tiny amounts to, over and
> > over again -- it's best to avoid that, although there are changes in
> > recent kernels which make it a lot better than it used to be.

We keep syslog in memory for a while without writing to flash, but we
do have some application logs that we have to write frequently.  Does
this cause more fragmentation?  Does JFFS2 rewrite the entire file
every time you update it?
If the changes to fix this problem is pretty isolated, can I backport
this to 2.6.21?

We also replace a bunch of the same files every day to test a new
release of our application software. After a week or so of doing this,
most of the developers end up with a real slugging NAND flash and we
have to end up erasing the entire NAND and start over.  I would like
to avoid this in the field.  We will be releasing software updates and
will have to upgrade the system. How does everyone deal with
situations like this? Is it standard practice to put the files that
change to a separate smaller partition and do the nand erase on it
before updating it?

I am confused by the behavior of the 'df' command. My test caused a
certain application to misbehave and wrote a bunch of info to the log.
 After this point, everytime I rebooted, df showed 62% is in use.
After a few minutes, this would go back down to 20%.  I had to remove
the logs to recover from the problem.  I didn't expect the flash to be
fragmented by the logs because we didn't remove and add a bunch of
files, we just updated the same file.

I also want to understand why the slabtop shows all the jffs2 slab
entries to be so high when we are booting up.
Here is an example:

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
201390 201390 100%    0.25K  13426       15     53704K jffs2_refblock
 11774   6863  58%    0.02K     58      203       232K jffs2_full_dnode
  6525   6509  99%    0.02K     45      145       180K jffs2_inode_cache
  5945   5280  88%    0.02K     41      145       164K jffs2_node_frag

What does each of these mean?  What causes the USE% to be 100%?

Thanks again for your help and comments.  I'll take any info I can get.

Nancy

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ