Skip to contentSkip to conversation

testcase for JFFS2

DISCUSSION [email protected] 1 participant 1 message Sep 7, 2006 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

Hi,

I'm doing white-box testing on jffs2. It's not the very latest code, but anyway ...

This tests the disk-full condition. On my system, this test causes bad values in c->free_size and c->dirty_size. c->free_size gets decremented too far, so I get values such as 0xfff838a8. c->dirty_size gets incremented too far, and I've seen it bigger than c->flash_size. It also causes problem for the GC thread. I have seen the GC thread trap, BUG, or go into an infinite loop.

Steps in this testcase.

[] Mount a clean jffs2 at /mnt. Mine is 16MB. I write all 0xFF there before mounting.

[] Create a file of random data that is 75% the size of the device. I use random data because it is harder to compress, making the partition fill up faster. Maybe you can use a file that is compressed already, as long as the file is about 3/4 the size of the partition. Call it file75 for naming sake.

[] Start filling it up by copying first file.

cp file75 /mnt/file1

This results in no error.

[] The next copy should exceed the partition size and cause a "no space" error. Resulting file is foreshortened.

cp file75 /mnt/file2

[] Next, remove the first file copied, which makes free space.

rm /mnt/file1

[] Copy over existing file2. There should be room for it.

cp file75 /mnt/file2

At this point I have seen unusual values in c->free_size and c->dirty_size.

[] The next copy should again fill up the partition.

cp file75 /mnt/file1

At this point, I have seen the GC thread print "Argh. No free space left for GC." and "Aborting GC thread." I have also seen the GC thread quietly go into an infinite loop.

Can anyone reproduce this bug? Thanks.

Monte Copeland