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. * ******************************************************************