 jffs2 and nand study jffs2 and nand study for the purposes of this discussion the term nand will mean both and and nand type flash memories both sharing similar properties from a system perspective a bit of history  history on my perspective not the history of jffs2 some years ago i wrote a flash file system for trimble trimble patented this system this ffs runs on nor flash and uses a concepts very similar to jffs to overcome problems associated with flash translation layers ftls and flash this ffs was rigorously tested for block failure stress tested in various ways and deliberately crashed with an emulator at critical stages to attempt to damage data integrity the ffs held up to all this thus when looking at jffs2 i can immediately understand why certain things are being done and various benefits of this approach over ftls at first i thought that using an ftl would be better than jffs2 for nand because nand has a different set of constraints after a bit of analysis i came around to thinking that using jffs2 would still be better than an ftl mainly because jffs2 dispenses with the need for a logical to physical translation layer  nor and nand the following table highlights some of the important properties of nor and nand flash this table holds true for most devices though there are some oddball devices out there  nor nand cost higher cost lower low density approx 8mb max device size higher density approx 256mb max device size linear random access like ram can be used for xip sector read write almost like a disk can t be used for xip structured as erasable blocks of 8kb to 128kb typical structured as erasable blocks of 32x512byte pages each page has 16bytes of extra management data endurance 100k to 1m erasures endurance 100k to 1m erasures erase time 1second erasable block erase time 2ms designed as rom replacements designed as mass storage replacements bytebybyte programming allowing singlebit modification any single bit can be modified from a 1 to a  by programming that byte however the only way to modify a  to a 1 is to erase the entire erasable block page or partialpage programming a page may be programmed a maximum number of times after that number of times the erasable block must be erased to allow further programming write operations can only modify 1s to 0s changing 0s to 1s requires an erasure random access programming pages must be written sequentially within a block no bad blocks when delivered but the devices wear out thus file systems should be fault tolerant bad blocks are expected when the devices are delivered further degradation is expected with use thus fault tolerance is an absolute necessity it is important to note the various differences between nor and nand flash because these are material in choosing the appropriate file systems for each in particular the erasure times are very different this impacts on the selection of appropriate garbage collection and erasure strategies nor s 1 second erasure time is significant and needs to be considered nand s 2msec erasure time is virtually insignificant the programming access restrictions that apply to nand do not apply to nor errors are far more likely in nand devices therefore error detection and correction is highly desirable nand flash is arranged in pages sectors of 512b and is inherently block structured both families of flash technology have significant usage restrictions which require special consideration when using the devices for file storage all flash memory blocks can only endure a limited number of erasure cycles some wear levelling strategy is required to prevent oftenused sectors wearing out faster sectors are smaller than an erasable block thus some garbage collection strategy is required to reclaim deleted dirty sectors to accomplish this the good data must be copied off the selected block so that the whole block can be erased without losing data if a part of a file needs to be overwritten it is a limitation of flash memory that the new data cannot just overwrite the data at the same physical location instead the data must be written at a new location thus some sort of logical to physical mapping layer ie ftl or alternative data storage approach is required eg jffs2 such logical to physical decoupling is also required to perform garbage collection  flash file systems in general flash file systems can essentially be implemented in two possible ways custombuilt file system ie the whole file system is designed so as to operate with flash memory an example of this is jffs2 or microsoft ffs2 use a standard file system with a custom block driver ie flash translation layer ftl each of these approaches have their pros and cons ftls are particularly suited to situations where the file system is preordained a custom file system is able to be more flash friendly  an appraisal of the jffs2 file system jffs and jffs2 achieve the logical decoupling between logical file positions and physical memory by using journaling for this to work the entire file system must be designed to support journaling as appropriate to flash memory this is not excessively restrictive with nonremovable media and embedded systems since there is no need to conform to a legacy file system layout jffs2 is designed to support nor flash but is currently not suited to nand flash since it does not handle bad blocks if this deficiency was addressed would it be a better choice for nand than an ftl probably not directly some other tweaks would be needed journaling is particularly useful garbage collection bad block handling and the restrictions which prevent flash sectors being overwritten mean that data in flash file systems is forever being moved around for ftls this means storing logical to physical mappings journaling neatly sidesteps this overhead one of the most thorny issues with flash file systems is that there are many patents covering both ftllike block drivers and various approaches to custom file systems these patents are particularly restrictive in ftllike block drivers especially the msystems patents jffs2 does not violate any patents i am aware of but it probably comes quite close to some particularly the trimble one thus it is highly beneficial to have a gpl ed system that can be extended work needed the following effort is required to make jffs2 work with nand new mtds for nand flash a new interface is probably required for nand since many of the functions for nor make no sense on nand bad block handling this could be handled in a norspecific layer although it should really be generically supported since nor can fail too ecc for data security code available from samsung www this can be handled as part of the write and read when a journaling node is written it should be verified if the data cannot be retrieved then a new node is created fixed size journaling nodes since nand is page oriented with limited writes per page this might make compression challenging maybe compression can t be used with nand anyway fixedsize journaling nodes probably reduce fragmentation too since there s an integer number of these per erasable block the following are possible improvements tuning garbage collection erasure strategies to suite nand eg nand erasure time is much faster using fixedsize nodes will probably strip out a chunk of code too attempting to use the spare 16 bytes per page for journalling tags if there s a useful amount of space left after ecc and bad block management thus my preliminary suggestion would be to add a nand subsystem to jffs2 this subsystem would use the same journaling file system core fixing the size of journaling nodes to pages of 512 bytes quite likely simplifies the interfaces node management and garbage collection error handling would fit within the nand subsystem since nor fails too bad block handling is really required for nor too whether the same management is appropriate for both is tbd ecc is only required for nand  references samsung and toshiba nand part data sheets and www samsung in particular has useful applications notes and code jffs2 presentation materials http sourcesredhatcom jffs2  laurie 6 june 2006 134pm  