This is an update on my in-field experience with yaffs2 compiled under linux 2.6.34 using yaffs2 code as of commit 4e188b08c5531f99f73383a85251e03a1e667b26 .
Our filesystem is remounted read-only during the boot process. No filesystem changes are expected under normal operation; we have been periodically testing filesystem integrity with rsync. Thus far one
instance of file corruption has occurred after 387 device-years of operation.
There was also some evidence of 3 filesystem anomalies (see below) but these were not reproducible: rsync reported files missing during its scan, but a later scan showed no issues. I'm ignoring the anomalies until there is more evidence of a problem.
The corruption was duplication of a 2k NAND page, seemingly overwriting whatever was originally there. The file in question was a compressed kernel image file. (This file is not normally read: it is the source file for the actual kernel stored on another NAND partition.) I did not verify whether rebooting corrected the issue before overwriting the corrupt file with a clean copy. This is possible, as yaffs stores some data structures in ram.
Per hexdump -C output below, the corruption is not due to NAND bitflips, as the entire 2k page is a duplicate of a page appearing later in the file. I do not know how to determine whether the corruption is due to the mtd layer or due to yaffs .
I would welcome any statement from yaffs developers identifying what branch or commit is recommended for use in production devices.
Rob Calhoun
commit 4e188b08c5531f99f73383a85251e03a1e667b26 Author: Charles Manning <cdhmanning@gmail.com> Date: Wed Jun 18 14:21:03 2014 +1200 Update to support Linux 3.14/3.15 Thanks to Andre Renaud for doing some of this.
$ ls -li /usr/sbin/chroot* 989 lrwxrwxrwx 1 root root 19 Aug 19 17:30 /usr/sbin/chroot -> /bin/busybox.nosuid 989 lrwxrwxrwx 1 root root 19 Aug 19 17:30 /usr/sbin/chroot -> /bin/busybox.nosuid