(My apologies if you receive this twice; I sent from the wrong account)
From: Sean Seifert <
sseifert@appareo.com<
mailto:sseifert@appareo.com>>
Date: 22 Oct 2014 6:26 PM
To: "
yaffs@lists.aleph1.co.uk<
mailto:yaffs@lists.aleph1.co.uk>" <
yaffs@lists.aleph1.co.uk<
mailto:yaffs@lists.aleph1.co.uk>>
Subject: [Yaffs] Current Yaffs2 Compilation Bugs with Some Fixes
(...)
Issue 4 (w/ fix):
------------------------------------------------------------------------------------------------------
Compilation broke on commit: 30f956c32c235e6b5fa77fb29965ababbd497561, Jul 22, 2014. Not all functions were updated for the new discard parameter. Here are the following that have been missed that discard parameter:
fs/yaffs2/yaffs_vfs.c:2205: error: too few arguments to function ‘yaffs_flush_whole_cache’
fs/yaffs2/yaffs_vfs.c:751: error: too few arguments to function ‘yaffs_flush_file’
fs/yaffs2/yaffs_vfs.c:781: error: too few arguments to function ‘yaffs_flush_file’
fs/yaffs2/yaffs_vfs.c:2192: error: too few arguments to function ‘yaffs_flush_file’
Simply adding the extra discard parameter to these functions makes compilation work. What is the proper number to pass to each? I added a "1" to each for the sake of getting this compiling in my code, but want to make sure that the correct parameter gets passed into the functions.
(...)
I can reproduce Sean Seifert's issue #4, also reported by
wikimfw@lotte.net in September.
I am also compiling an updated version of yaffs on an older kernel (2.6.34) following our discovery of very severe data corruption issues traced to the obsolete version of yaffs we were using (99c62e39578113a798483b5dc6c13a80737163f1 on branch yaffs2, from March 2010.) Thank you to William Juul for his help in diagnosing this!
Like Sean Seifert I could not get yaffs master HEAD to compile due the inconsistent definitions of yaffs_flush_file() in yaffs_guts and yaffs_vfs.
Rather than modify the source I rolled back to the commit before the new cache policy changes (to 4e188b08c5531f99f73383a85251e03a1e667b26, "Update to support Linux 3.14/3.15") and was able to successfully build using that tree. We are now testing that build for deployment.
Question for Charles Manning/branch maintainers: Is there some release branch we should be using in lieu of integrating branch master at an arbitrary commit? Master seems like a work in progress at the moment.
re: Sean Seifert's issues 1 and 2:
I did not encounter these with kernel 2.6.34 and an (old-ish) version of gcc (4.4.7).
re: Sean Seifert's issues 3 and 5:
Sean, if I read your email correctly you have a yaffs2 system with out-of-band tags and no yaffs ECC on those tags.
Our defconfig (old and new) use the default (do not disable tag ECC) i.e.
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
so we did not encounter this problem.
The Kconfig documentation says "This behavior can also be overridden with tags_ecc_on and tags_ecc_off mount options" so you may be able to compile with ECC tags on but then disable tag ECC at runtime with your kernel command line mount argument and still mount your filesystem.
Based on /proc/yaffs we are using out-of-band area for tags. It is probably desirable to to have YAFFS do ECC on the tags, because in many flash devices the OOB area is not entirely protected by ECC. For example we use Micron MT29F2G16ABBEAHC, which I believe is a typical SLC NAND device. It has 16 OOB bytes (2 bytes bad block marker, 8 bytes ECC parity, 6 bytes "user data") for each 512 byte partial page, so a full 2048-byte page has 6 * 4 = 24 user bytes, which are not fully protected by ECC using either the on-chip correction or (SoC controller + MTD driver). I assume this is why YAFFS does tag ECC by default on OOB tags even when the user data is protected at the MTD layer and below.
I find the whole use of OOB a bit difficult to follow. yaffs_packed_tags2 seems to comprise (4 x uint32) of tag data plus (uint8, uint32, unit32) of ECC data for a total of 25 bytes, one byte more than space available for user data. Clearly there is something I am not understanding here.
Anyway, we are using the following defconfig:
CONFIG_YAFFS_FS=y
CONFIG_YAFFS_YAFFS1=y
# CONFIG_YAFFS_9BYTE_TAGS is not set
# CONFIG_YAFFS_DOES_ECC is not set
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y
# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set
# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set
# CONFIG_YAFFS_DISABLE_BACKGROUND is not set
# CONFIG_YAFFS_DISABLE_BAD_BLOCK_MARKING is not set
CONFIG_YAFFS_XATTR=y
and are able to read our existing filesystem without issues. These are all defaults set by patch-ker.sh for 2.6.34 except for CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED, which I carried forward from our old defconfig.
-Rob Calhoun
(text/plain)