Re: JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount

Re: JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount

[Artem Bityutskiy]

Hi,

On Thu, 2007-03-01 at 18:41 +0000, Josh Green wrote:
> I'm currently working on a Linux project with a Philips LPC3180 based
> system.  The Linux support for this board seems to be under development
> by Philips and is not yet in the main Linux tree (we received support as
> a patch).  So this problem could very well be related to the drivers we
> received for this platform, but I wanted to check if anyone else has
> experienced similar behavior or have any pointers as to the cause.

I have never heard of such a really weird problem.

> Linux kernel 2.6.10 with patch from Philips

Ancient kernel, not a lot of people are interested in digging it.

> If anyone has any helpful information they could share in regards to
> this problem, I would appreciate it.  This could very well be a jffs2
> specific problem, but the jffs list seems rather dead, and there is a
> lot related to jffs2 on this list.  Please let me know if I'm posting to
> the wrong list though.

It's the right list.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount

[Josh Green]

I'm currently working on a Linux project with a Philips LPC3180 based
system.  The Linux support for this board seems to be under development
by Philips and is not yet in the main Linux tree (we received support as
a patch).  So this problem could very well be related to the drivers we
received for this platform, but I wanted to check if anyone else has
experienced similar behavior or have any pointers as to the cause.

Description of problem:

After mounting jffs2 file system it gradually goes from 45% full to 100%
in the matter of ~20 seconds (as reported by df).  Doing a du on the top
directory of the file system shows the same amount of data as when it is
first mounted.  Unmounting and remounting still shows 100% usage, and no
files can be written (device full).  Rebooting and then remounting the
file system, then goes through the 45% to 100% gradual fill up again.
No kernel error messages are received when mounting or unmounting.  The
actual jffs2 image file which gets flashed is ~3MB and contains ~6MB of
data (which gets zlib compressed as shown by mkfs.jffs2 -v).  The flash
partition is ~10MB.

I was able to successfully flash other parts of the flash memory (the
first partition) with kernel, uboot, etc.  So I'm pretty sure that is
working correctly, and the files in the jffs2 file system are indeed
there after mounting.


Details of system:

Linux kernel 2.6.10 with patch from Philips
Cross compiler gcc 3.4.2 using scratchbox
Flash is an ST Micro NAND256R3A 32MB chip with 8 bit bus

MTD messages on boot, showing the 2 partitions I created.  The erase
block size is 0x4000 (16KiB), as reported by /proc/mtd.

NAND device: Manufacturer ID: 0x20, Chip ID: 0x35 (ST Micro NAND 32MiB 1,8V 8-bit)
Scanning device for bad blocks
Creating 2 MTD partitions on "NAND 32MiB 1,8V 8-bit":
0x00008000-0x00c00000 : "rootfs-kernel-uboot"
0x00c00000-0x01640000 : "jffs2"

jffs2 file system created with the following command:
mkfs.jffs2 -n -e 16384 -o rootfs_jffs2.img -r target

Flashed with the following commands on the target:
flash_erase /dev/mtdchar1 0 656
nandwrite -p -s 0 /dev/mtdchar1 rootfs_jffs2.img

df immediately after mount and ~20 seconds later (going gradually
upwards).

Filesystem           1k-blocks      Used Available Use% Mounted on              
/dev/mtdblock1           10496      4672      5824  45% /mnt/disk               

Filesystem           1k-blocks      Used Available Use% Mounted on              
/dev/mtdblock1           10496     10496         0 100% /mnt/disk               


If anyone has any helpful information they could share in regards to
this problem, I would appreciate it.  This could very well be a jffs2
specific problem, but the jffs list seems rather dead, and there is a
lot related to jffs2 on this list.  Please let me know if I'm posting to
the wrong list though.

Best regards,
	Josh Green

Re: JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount

[Vitaly Wool]

Artem Bityutskiy wrote:

>>Linux kernel 2.6.10 with patch from Philips
>>    
>>
>
>Ancient kernel, not a lot of people are interested in digging it.
>  
>
Absolutely, especially given the possible side effects of the "patch
from Philips" no one here has actually seen ;-)
What I'd suggest is to try quickporting the board support and flash
driver to the latest community kernel and reproducing the problem with
this new setup.

Vitaly

Re: JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount

[Josh Green]

On Thu, 2007-03-01 at 19:07 -0500, Pete MacKay wrote:
> I tried getting this part to work with 2.6.18 and saw similar behavior
> at one point, but we've since changed hardware to use OneNAND.  One
> thought I have is to try padding the file system to use the full
> partition, so you'd add "--pad=0xa40000" to the mkfs.jffs2 command line,
> and make sure you're using a version of mtd-utils that correctly writes
> the OOB on that device (another problem we had).  BTW, the mkfs.jffs2 we
> use has a bug where it doesn't parse the '-p' option properly but does
> with '--pad='.  Good luck!
> 

I tried the pad option before with stranger results (lots of error
output during mount).  Thanks for the tips on the mtd-utils and the OOB
stuff, in fact I suspect that could very well be what I'm experiencing.
Something wrong with the way the OOB stuff is being written.  I turned
on verbose errors for the MTD sub system and I get a load of these
messages after mounting, which continue until the partition indicates
that it is full (gee if that isn't suspicious I don't know what is).
There were also messages related to the garbage collector interspersed
with these when I turned up the verbosity of error reporting.

nand_write_oob: Attempt to write past end of page
nand_write_oob: Attempt to write past end of page
...

> P.S. If I had it to do all over again I'd have made maps of the factory
> marked bad blocks, as I had to 'nuke' the chip by marking them all good
> again (U-boot lets you do this with a conditional, but created the need
> for it in the first place by writing the cleanmarker in the wrong place
> in the OOB - namely the bad block marker!).
> 

Fortunately with the device I have I don't believe there are any bad
blocks (at least there were none reported when I got it, although that
could also be a bad thing).

Thanks go as well to the others who responded.  I'm well aware that this
kernel is outdated.  Unfortunately its what we have to work with for
now.  I'll be quite happy when this platform is supported in the main
kernel tree.

Best regards,
	Josh Green