Hello,
in my quest to find the best file system to use, I've incurred in some more errors while using YAFFS2 file system on my EVM board. Basically the problem happens when using "small partitions" while the same operations do not fail when using "big partitions". I have not been able to trace the exact size, but the same operations repeated on the same board using 2 different mtd devices, with different sizes, have different results. Notice that both mtd partitions are a lot bigger than the real data I am trying to put in.
Moreover when the problem happens the bad block table of the device becomes corrupt until next reboot.
This is my MTD setup:
dev: size erasesize name
mtd0: 006c0000 00020000 "bootloader"
mtd1: 00060000 00020000 "params1"
mtd2: 00060000 00020000 "params2"
mtd3: 00400000 00020000 "Kernel1"
mtd4: 00400000 00020000 "Kernel2"
mtd5: 01800000 00020000 "Root1"
mtd6: 01800000 00020000 "Root2"
mtd7: 00400000 00020000 "User1"
mtd8: 00400000 00020000 "User2"
mtd9: 7b880000 00020000 "Spare"
mtd10: 00002000 00000010 "spi_eeprom"
In my test I'll use mtd6 (64MB partition) and mtd9 (nearly 2GB partition, but with a 512GB partition the results are the same).
The operation without problems: I erase mtd9, mount a new yaffs2 file system on it, untar my root in it.
# flash_eraseall /dev/mtd9
Erasing 128 Kibyte @ 1ba0000 -- 1 % complete.
Skipping bad block at 0x01bc0000
Erasing 128 Kibyte @ dae0000 -- 11 % complete.
Skipping bad block at 0x0db00000
...
there are some bad blocks, but they do not cause any problem, as expected.
# mount -t yaffs2 /dev/mtdblock9 /mnt/point
No errors on mount command
# time tar -x -C /mnt/point -f /mnt/nfs/rootfs.arm.tar.gz
real 2m 10.99s
user 0m 0.34s
sys 1m 58.84s
untarring on yaffs2 is a bit slow, but it works as expected. No errors, the file system can be unmounted and mounted back. Notice the output of df says that the used space is a lot smaller than the partition. This is correct.
# df
Filesystem 1K-blocks Used Available Use% Mounted on
mtd:Root1 24576 8464 16112 34% /
tmpfs 25600 0 25600 0% /upgrade
tmpfs 1024 64 960 6% /tmp
tmpfs 1024 16 1008 2% /root
tmpfs 1024 64 960 6% /dev
tmpfs 1024 64 960 6% /var
tmpfs 1024 424 600 41% /var/log
/dev/mtdblock7 4096 400 3696 10% /flashrw
/dev/mtdblock9 2023936 8368 2015568 0% /mnt/point
Now, the incorrect bahavior: I'll repeat the same operation on mtd6, a 64MB partition.
# flash_eraseall /dev/mtd6
Erasing 128 Kibyte @ 17e0000 -- 99 % complete.
No bad blocks, good.
# mount -t yaffs2 /dev/mtdblock6 /mnt/point
Mounting is fine, as in previous case. But not untarring the data in the fs causes problems. Notice that using "cp" to copy the data in causes the same.
# tar -x -C /mnt/point -f /mnt/nfs/rootfs.arm.tar
tar: can't open './usr/share/zoneinfo/Africa/Sao_Tome': Cannot allocate memory
At some point during untar, the system went out of memory.
Notice the output of dmesg, truncated since it is too long:
# dmesg
> Block 111 retired
Block 111 is in state 9 after gc, should be erased
yaffs: Block struck out
nand_update_bbt: Out of memory
nand_erase: attempt to erase a bad block at page 0x00006ac0
yaffs: Failed to mark bad and erase block 112
**>> Block 112 retired
Block 112 is in state 9 after gc, should be erased
yaffs: Block struck out
yaffs: Block struck out
nand_update_bbt: Out of memory
...
But what's worse is that the bad block table in memory is corrupted: notice the result of flash_eraseall repeated on the partition:
# umount /mnt/point
# flash_eraseall /dev/mtd6
Skipping bad block at 0x00000000
Skipping bad block at 0x00020000
Skipping bad block at 0x00040000
Skipping bad block at 0x00060000
Skipping bad block at 0x00080000
Skipping bad block at 0x000a0000
Skipping bad block at 0x000c0000
...
But the previous flash_eraseall on the same mtd device did not detect any problem. If I reboot the board, the problems with bad blocks disappear.
