RE: Flash disks and FFS layout heuristics



I came late to this discussion, so pardon me if I'm repeating stuff
that's already been discussed.

You can guess a lot from vendor specs, but NAND flash requires
experience before you understand the nuances; especially since the
vendors tend not to document most of what you need to know to get good
performance and reliability from a flash device.

There are, basically, two approaches to using NAND devices. What PHK
calls "flash adapation layer" or, sometimes, "flash translation layer"
is widely used in devices that are meant to be seen as removable ms-dos
file system devices, such as almost every USB NAND based flash device on
the market. It is also used in at least two commercial flash file
systems intended for embedded flash. It is also an approach available to
the Linux MTD layer, although not used by any of the Linux filesystems.
This approach works well enough for specific usage patterns and you will
find several successful embedded devices on the CE market place that use
it.

The second approach is to have a 'flash aware filesystem', which
understand the write/read/erase properties of NAND flash parts. There
are three variants on this approach that I'm aware of. The first takes a
'traditional' filesystem like FFS and, in effect, adds a flash
translation layer. The second takes a log-like file system and adapts
its GC to NAND. The third approach is to write a file system specific to
NAND devices from scratch. PalmOS Garnet's NAND file system is an
example of the first. The modified version of LFS that Mike Chen and I
did for PalmOS Cobalt is an example of the second. The MTD based file
system jffs2 is an example of the third, and a cautionary tale for those
who would write their own.

In addition to the various points Matt Dillon has figured out from
reading specs, there are several features of NAND parts that I haven't
seen mentioned here that play a fairly important role in designing file
systems around them. These include, but are probably not limited to:

1) Large page versus small page NAND
2) Broken or poorly performing hardware, especially ECC generation and
write verification
3) Adjacent write effect

Some interesting properties to take into account when designing a NAND
file system:

1) No block can be assumed good, which means you have to scan the device
to find your metadata starting point at boot time.

2) Small page NAND has less 'spare' available in the spare region than
large page NAND, which means that you can do optimizations for large
page nand that you can't for small.

3) write-back caching of writes makes NAND parts less reliable
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: File system is not working in Retail Version in WinCE 5.0
    ... I am using the NAND Flash for FAT File System only and I am using the ram ... debug and retail versions after that the loading sequences differs for each. ... As per your suggestion if there is problem in our FMD, for NAND file system ...
    (microsoft.public.windowsce.embedded)
  • Re: File system is not working in Retail Version in WinCE 5.0
    ... I'm using a NOR based flash, ... and when I'm in debug mode, ... As per your suggestion if there is problem in our FMD, for NAND file system ...
    (microsoft.public.windowsce.embedded)
  • Re: File system is not working in Retail Version in WinCE 5.0
    ... I'm using a NOR based flash, ... and when I'm in debug mode, ... As per your suggestion if there is problem in our FMD, for NAND file system ...
    (microsoft.public.windowsce.embedded)
  • Re: File system is not working in Retail Version in WinCE 5.0
    ... As per your suggestion if there is problem in our FMD, for NAND file system ... the Microsoft in the public Directory and i am using tthe Strata P30 flash. ...
    (microsoft.public.windowsce.embedded)
  • Re: FreeBSDs embedded agenda
    ... you write persistent data to the NAND disk. ... the file system write enabled synchronously. ... If you look at, for instance, the evolution of OMAP support ... support service that provides an abstraction like the bus abstraction ...
    (freebsd-current)