On Wed, 21 Sep 2005, Wookey wrote:
> +++ Michael Erickson [05-09-20 17:57 -0500]:
> > Sergey,
> >
> >
> > At the very least, you should try taking a breath before sending an
> email
> > that makes you look like an incompetent, posturing buffoon.
>
> The YAFFS list's first flame-war :-)
It's not. Sorry for being rude but I hate poor job (khaltura in Russian).
That's what YAFFS/YAFFS2 is still stands at.
OK, now for the yesterday's torture test. First of all, YAFFS failed
miserably. Now about setup and results.
We have one ST 64 Mbyte NAND chip on our board, the name is NAND512R3A. It
has 2 partitions, 12 Mbyte for the application software and the rest for the
root FS. System runs on Atmel's AT91RM9200 ARM9 SOC. Das U-Boot blows life
in the system when it's powered up. Kernel (almost vanilla 2.6.12 with some
added drivers of our own) lives in a partition of Atmel Dataflash and is
loaded and run by U-Boot. This part does not touch NAND. Root filesystem is
mounted from the second (48 Mbyte) NAND partition that is /dev/mtdblock2 in
our case (mtd0 is Atmel Dataflash that gets detected first.) Mounted
filesystems were one NFS on /mnt, mtd2 on /, and mtd1 (12 Mbyte) on
/opt/vadatech. The "torture" script had been copying a megabyte file (libc)
from NFS to YAFFS, renaming it, moving it from one partition to another one
then deleting everything and starting all over again. Here is the script:
=== Cut ===
#!/bin/sh
while true
do
cp -f /mnt/lib/libc-2.3.5.so /tmp
mv -f /tmp/libc-2.3.5.so /tmp/libc-2.3.5.so-moved
cp /tmp/libc-2.3.5.so-moved /opt/vadatech
mv /opt/vadatech/libc-2.3.5.so-moved /opt/vadatech/libc-2.3.5.so
mv -f /opt/vadatech/libc-2.3.5.so /tmp/libc-2.3.5.so
mkdir /tmp/1
mv -f /tmp/libc-2.3.5.so /tmp/1
rm -f /tmp/libc-2.3.5.so-moved
rm -rf /tmp/1
done
=== Cut ===
It survived the torture for something like 5 minutes. After that the smaller
FS got trashed. 118 blocks got marked bad, directory structure is totally
damaged, FS is unusable, not possible to delete those funny "?|" files
(directories?) by regular file tools. The bigger one, that was mounted as /
coped surprisingly well, no problems found. Filesystems were put to NAND
partitions with mkyaffs utility. Root FS (circa 30 MBytes) image has been
created by mkyaffsimage utility and given to mkyaffs. The smaller filesystem
was created without an image, i.e. empty. BTW, it looks like the more stuff
an FS has on initial mount the better it behaves afterwards.
OK, the script started generated errors like this after 5 or so minutes:
=== Cut ===
[root@arm ~]# ./torture
mv: unable to rename /opt/vadatech/libc-2.3.5.so-moved': Directory not empty
mv: /opt/vadatech/libc-2.3.5.so: No such file or directory
mv: unable to rename /tmp/libc-2.3.5.so': No such file or directory
mv: unable to rename /opt/vadatech/libc-2.3.5.so-moved': Directory not empty
mv: /opt/vadatech/libc-2.3.5.so: No such file or directory
mv: unable to rename /tmp/libc-2.3.5.so': No such file or directory
mv: unable to rename /opt/vadatech/libc-2.3.5.so-moved': Directory not empty
mv: /opt/vadatech/libc-2.3.5.so: No such file or directory
mv: unable to rename /tmp/libc-2.3.5.so': No such file or directory
mv: unable to rename /opt/vadatech/libc-2.3.5.so-moved': Directory not empty
mv: /opt/vadatech/libc-2.3.5.so: No such file or directory
mv: unable to rename /tmp/libc-2.3.5.so': No such file or directory
=== Cut ===
Syslog had been flooded with messages like this:
=== Cut ===
Dec 31 16:30:55 kernel: page 1040 in gc has no object
Dec 31 16:30:55 kernel: page 1041 in gc has no object
Dec 31 16:30:55 kernel: page 1042 in gc has no object
Dec 31 16:30:55 kernel: page 1043 in gc has no object
Dec 31 16:30:55 kernel: page 1044 in gc has no object
Dec 31 16:30:55 kernel: page 1045 in gc has no object
Dec 31 16:30:55 kernel: page 1046 in gc has no object
Dec 31 16:30:55 kernel: page 1047 in gc has no object
Dec 31 16:30:55 kernel: page 1048 in gc has no object
Dec 31 16:30:55 kernel: page 1049 in gc has no object
Dec 31 16:30:55 kernel: page 1050 in gc has no object
Dec 31 16:30:55 kernel: page 1051 in gc has no object
Dec 31 16:30:55 kernel: page 1054 in gc has no object
Dec 31 16:30:55 kernel: page 1055 in gc has no object
Dec 31 16:30:55 kernel: **>> Block 717 retired
Dec 31 16:30:55 kernel: page 23040 in gc has no object
Dec 31 16:30:55 kernel: page 23041 in gc has no object
Dec 31 16:30:55 kernel: page 23042 in gc has no object
Dec 31 16:30:55 kernel: page 23043 in gc has no object
Dec 31 16:30:55 kernel: page 23044 in gc has no object
Dec 31 16:30:55 kernel: page 23045 in gc has no object
Dec 31 16:30:55 kernel: page 23046 in gc has no object
Dec 31 16:30:55 kernel: page 23047 in gc has no object
=== Cut ===
/proc/yaffs after the script was stopped:
=== Cut ===
YAFFS built:Sep 20 2005 20:47:37
$Id: yaffs_fs.c,v 1.31 2005/09/21 01:14:03 charles Exp $
$Id: yaffs_guts.c,v 1.19 2005/09/20 05:08:50 charles Exp $
Device 0 "Root FS (Linux)"
startBlock......... 0
endBlock........... 3327
chunkGroupBits..... 1
chunkGroupSize..... 2
nErasedBlocks...... 865
nTnodesCreated..... 9100
nFreeTnodes........ 351
nObjectsCreated.... 5600
nFreeObjects....... 22
nFreeChunks........ 34231
nPageWrites........ 210850
nPageReads......... 249612
nBlockErasures..... 4822
nGCCopies.......... 1583
garbageCollections. 4822
passiveGCs......... 4822
nRetriedWrites..... 0
nRetireBlocks...... 0
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 1
cacheHits.......... 0
nDeletedFiles...... 69
nUnlinkedFiles..... 77
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 0
Device 1 "Application Software"
startBlock......... 0
endBlock........... 767
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 316
nTnodesCreated..... 200
nFreeTnodes........ 22
nObjectsCreated.... 100
nFreeObjects....... 72
nFreeChunks........ 10182
nPageWrites........ 65023
nPageReads......... 55624
nBlockErasures..... 1354
nGCCopies.......... 23
garbageCollections. 1540
passiveGCs......... 1540
nRetriedWrites..... 0
nRetireBlocks...... 383
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 0
nDeletedFiles...... 25
nUnlinkedFiles..... 25
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 0
=== Cut ==
Those "**>>mtd ecc unfixed" messages were explicitely disabled (#if 0'd)
otherwise I wouldn't have anything but them in syslog.
I do know that "Fix your MTD" mantra. Please let me know what can and should
I fix in a stock CVS MTD (something like 10 of them tried for the last 4
months with exactly the same sorry result.) The usual monkey drum dances
mentioned in the "FAQ" were performed several times with no result. MTD
devices were explicitely setup to that YAFFS nand_oobinfo layout with no
result. NAND ECC were disabled in favor of YAFFS own ECC (both "right" and
"wrong" order) with no result.
Conclusion: YAFFS (dunno about YAFFS2, don't have hardware to test) in it's
present state can only be used for a non-critical experimenter's system with
a very light FS usage where total loss of data is OK. One must be totally
out of his mind to even think of using it in a production environment of any
kind.
I don't even mention that FS tools do not exist...
P.S. A small archive with those ancient YAFFS1 tools bandaided for 2.6
kernels is attached. No warranties, no promises, but it seems to work
for me somehow. The mkyaffsimage builds with host CC for the host
usage, mkyaffs is build with a cross-CC for using on a target
platforms. CROSS_COMPILE and PLAT_CFLAGS (target platform flags) should
be passed to make.
---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
(text/plain)
