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
