nuttx/fs/smartfs/README.txt

SMARTFS README
^^^^^^^^^^^^^^

This README file contains information about the implementation of the NuttX
Sector Mapped Allocation for Really Tiny (SMART) FLASH file system, SMARTFS.

Contents:

  Features
  General operation
  SMARTFS organization
  Headers
  Multiple mount points
  SMARTFS Limitations
  ioctls
  Things to Do

Features
========

  This implementation is a full-feature file system from the perspective of
  file and directory access (i.e. not considering low-level details like the
  lack of bad block management).  The SMART File System was designed specifically
  for small SPI based FLASH parts (1-8 Mbyte for example), though this is not
  a limitation.  It can certainly be used for any size FLASH and can work with
  any MTD device by binding it with the SMART MTD layer and has been tested with
  devices as large as 128MByte (using a 2048 byte sector size with 65534 sectors).
  The FS includes support for:
    - Multiple open files from different threads.
    - Open for read/write access with seek capability.
    - Appending to end of files in either write, append or read/write
      open modes.
    - Directory support.
    - Support for multiple mount points on a single volume / partition (see
      details below).
    - Selectable FLASH Wear leveling algorithym
    - Selectable CRC-8 or CRC-16 error detection for sector data
    - Reduced RAM model for FLASH geometries with large number of sectors (16K-64K)

General operation
=================

  The SMART File System divides the FLASH device or partition into equal
  sized sectors which are allocated and "released" as needed to perform file
  read/write and directory management operations.  Sectors are then "chained"
  together to build files and directories.  The operations are split into two
  layers:

    1.  The MTD block layer (nuttx/drivers/mtd/smart.c).  This layer manages
        all low-level FLASH access operations including sector allocations,
        logical to physical sector mapping, erase operations, etc.
    2.  The FS layer (nuttx/fs/smart/smartfs_smart.c).  This layer manages
        high-level file and directory creation, read/write, deletion, sector
        chaining, etc.

  SMART MTD Block layer
  =====================

  The SMART MTD block layer divides the erase blocks of the FLASH device into
  "sectors".  Sectors have both physical and logical number assignments.
  The physicl sector number represents the actual offset from the beginning
  of the device, while the logical sector number is assigned as needed.
  A physical sector can have any logical sector assignment, and as files
  are created, modified and destroyed, the logical sector number assignment
  for a given physical sector will change over time.  The logical sector
  number is saved in the physical sector header as the first 2 bytes, and
  the MTD layer maintains an in-memory map of the logical to physical mapping.
  Only physical sectors that are in use will have a logical assignment.

  Also contained in the sector header is a flags byte and a sequence number.
  When a sector is allocated, the COMMITTED flag will be "set" (changed from
  erase state to non-erase state) to indicate the sector data is valid.  When
  a sector's data needs to be deleted, the RELEASED flag will be "set" to
  indicate the sector is no longer in use.  This is done because the erase
  block containing the sector cannot necessarily be erased until all sectors
  in that block have been "released".  This allows sectors in the erase
  block to remain active while others are inactive until a "garbage collection"
  operation is needed on the volume to reclaim released sectors.

  The sequence number is used when a logical sector's data needs to be
  updated with new information.  When this happens, a new physical sector
  will be allocated which has a duplicate logical sector number but a
  higher sequence number.  This allows maintaining flash consistency in the
  event of a power failure by writing new data prior to releasing the old.
  In the event of a power failure causing duplicate logical sector numbers,
  the sector with the higher sequence number will win, and the older logical
  sector will be released.

  The SMART MTD block layer reserves some logical sector numbers for internal
  use, including

    Sector 0:     The Format Sector.  Has a format signature, format version, etc.
                  Also contains wear leveling information if enabled.
    Sector 1-2:   Additional wear-leveling info storage if needed.
    Sector 3:     The 1st (or only) Root Directory entry
    Sector 4-10:  Additional root directories when Multi-Mount points are supported.
    Sector 11-12: Reserved

  To perform allocations, the SMART MTD block layer searches each erase block
  on the device to identify the one with the most free sectors.  Free sectors
  are those that have all bytes in the "erased state", meaning they have not
  been previously allocated/released since the last block erase.  Not all
  sectors on the device can be allocated ... the SMART MTD block driver must
  reserve at least one erase-block worth of unused sectors to perform
  garbage collection, which will be performed automatically when no free
  sectors are available.  When wear leveling is enabled, the allocator also takes
  into account the erase block erasure status to maintain level wearing.

  Garbage collection is performed by identifying the erase block with the most
  "released" sectors (those that were previously allocated but no longer being
  used) and moving all still-active sectors to a different erase block.  Then
  the now "vacant" erase block is erased, thus changing a group of released
  sectors into free sectors.  This may occur several times depending on the
  number of released sectors on the volume such that better "wear leveling"
  is achieved.

  Standard MTD block layer functions are provided for block read, block write,
  etc. so that system utilities such as the "dd" command can be used,
  however, all SMART operations are performed using SMART specific ioctl
  codes to perform sector allocate, sector release, sector write, etc.

  A couple of config items that the SMART MTD layer can take advantage of
  in the underlying MTD drivers is SUBSECTOR_ERASE and BYTE_WRITE.  Most
  flash devices have a 32K to 128K Erase block size, but some of them
  have a smaller erase size available also.  Vendors have different names
  for the smaller erase size; In the NuttX MTD layer it is called
  SUBSECTOR_ERASE.  For FLASH devices that support the smaller erase size,
  this configuration item can be added to the underlying MTD driver, and
  SMART will use it.  As of the writing of this README, only the
  drivers/mtd/m25px.c driver had support for SUBSECTOR_ERASE.

  The BYTE_WRITE config option enables use of the underlying MTD driver's
  ability to write data a byte or a few bytes at a time vs. a full page
  at at time (which is typically 256 bytes).  For FLASH devices that support
  byte write mode, support for this config item can be added to the MTD
  driver.  Enabling and supporting this feature reduces the traffic on the
  SPI bus considerably because SMARTFS performs many operations that affect
  only a few bytes on the device.  Without BYTE_WRITE, the code must
  perform a full page read-modify-write operation on a 256 or even 512
  byte page.

  Wear Leveling
  =============

  When wear leveling is enabled, the code automatically writes data across
  the entire FLASH device in a manner that causes each erase block to be
  worn (i.e. erased) evenly.  This is accomplished by maintaining a 4-bit
  wear level count for each erase block and forcing less worn blocks to be
  used for writing new data.  The code maintains each block's erase count
  to be within 16 erases of each other, though through testing, the span
  so far was never greater than 10 erases of each other.

  As the data in a block is modified repeatedly, the erase count will
  increase.  When the wear level reaches a value of 8 or higher, and the block
  needs to be erased (because the data in it has been modified, etc.) the code
  will select an erase block with the lowest wear count and relocate it to
  this block (with the higher wear count).  The idea being that a block with
  the lowest wear count contains more "static" data and should require fewer
  additional erase operations.  This relocation process will continue on the
  block (only when it needs to be erased again).


  When the wear level of all erase blocks has increased to a level of
  SMART_WEAR_MIN_LEVEL (currently set to 5), then the wear level counts
  will all be reduced by this value.  This keeps the wear counts normalized
  so they fit in a 4-bit value.  Note that theoretically, it *IS* possible to
  write data to the flash in a manner that causes the wear count of a single
  erase block to increment beyond it's maximum value of 15.  This would have
  to be a very, very, very specific and un-predictable write sequence though
  as data is always spread out across the sectors and relocated dynamically.
  In the extremely rare event this does occur, the code will automatically
  cap the maximum wear level at 15 an increment an "uneven wear count"
  variable to indicate the number times this event has occurred.  So far, I
  have not been able to get the wear count above 10 though my testing.

  The wear level status bits are saved in the format sector (logical sector
  number zero) with overflow saved in the reserved logical sectors one and
  two.  Additionally, the uneven wear count (and total block erases if
  PROCFS is enabled) are stored in the format sector.  When the PROCFS file
  system is enabled and a SMARTFS volume is mounted, the SMART block driver
  details and / or wear level details can be viewed with a command such as:

     cat /proc/fs/smartfs/smart0/status
        Format version:    1
        Name Len:          16
        Total Sectors:     2048
        Sector Size:       512
        Format Sector:     1487
        Dir Sector:        8
        Free Sectors:      67
        Released Sectors:  572
        Unused Sectors:    817
        Block Erases:      5680
        Sectors Per Block: 8
        Sector Utilization:98%
        Uneven Wear Count: 0

     cat /proc/fs/smartfs/smart0/erasemap
        DDDCGCCDDCDCCDCBDCCDDGBBDBCDCCDDDCDDDDCCDDCCCGCGDCCDBCDDGBDBDCDD
        BCCCDDCCDDDCBCCDGCCCBDDCCGBBCBCCGDCCDCBDBCCCDCDDCDDGCDCGDCBCDBDG
        BCDDCDCBGCCCDDCGBCCGBCCBDDBDDCGDCDDDCGCDDBCDCBDDBCDCGDDCCBCGBCCC
        GCBCCGCCCDDDBGCCCCGDCCCCCDCDDGBBDACABDBBABCAABCCCDAACBADADDDAECB

  Enabling wear leveling can increase the total number of block erases on the
  device in favor of even wearing (erasing).  This is caused by writing /
  moving sectors that otherwise don't need to be written to move static data
  to the more highly worn blocks.  This additional write requirement is known
  as write amplification.  To get an idea of the amount of write amplification
  incurred by enabling wear leveling, I conducted the smart_test example using
  four different configurations (wear, no wear, CRC-8, no CRC) and the results
  are shown below.  This was done on a 1M Byte simulated FLASH with 4K erase
  block size, 512 sectors per byte.  The smart_test creates a 700K file and
  then performs 20,000 random seek, write, verify tests.  The seek write forces
  a multitude of sector relocation operations (with or without CRC enabled),
  causing a boatload of block erases.

  Enabling wear leveling actually decreased the number of erase operations
  with CRC enabled or disabled.  This is only a single test point based one
  testing method ... results will likely vary based on the method the data
  is written, the amount of static vs. dynamic data, the amount of free space
  on the volume, and the volume geometry (erase block size, sector size, etc.).

  The results of the tests are:

    Case                          Total Block erases
    ================================================
    No wear leveling     CRC-8         6632
    Wear leveling        CRC-8         5585

    No wear leveling     no CRC        6658
    Wear leveling        no CRC        5398


  Reduced RAM model
  =================

  On devices with a larger number of logical sectors (i.e. a lot of erase
  blocks with a small selected sector size), the RAM requirement can become
  fairly significant.  This is caused by the in-memory sector map which
  keeps track of the logical to physical mapping of all sectors.  This is
  a RAM array which is 2 * totalsectors in size.  For a device with 64K
  sectors, this means 128K of RAM is required just for the sector map, not
  counting RAM for read/write buffers, erase block management, etc.

  So a reduced RAM model has been added which only keeps track of which
  logical sectors have been used (a table which is totalsectors / 8 in size)
  and a configurable sized sector map cache.  Each entry in the sector map
  cache is 6 bytes (logical sector, physical sector and cache entry age).
  ON DEVICES WITH SMALLER TOTAL SECTOR COUNT, ENABLING THIS OPTION COULD
  ACTUALLY INCREASE THE RAM FOOTPRINT INSTEAD OF REDUCE IT.

  The sector map cache size should be selected to balance the desired RAM
  usage and the file system performance.  When a logical to physical sector
  mapping is not found in the cache, the code must perform a physical search
  of the FLASH to find the requested logical sector.  This involves reading
  the 5-byte header from each sector on the device until the sector is
  found.  Performing a full read, seek or open for append on a large file
  can cause the sector map cache to flush completely if the file is larger
  than (cache entries * sector size).  For example, in a configuration with
  256 cache entries and a 512 byte sector size, a full read, seek or open for
  append on a 128K file will flush the cache.

  An additional RAM savings is realized on FLASH parts that contain 16 or
  fewer logical sectors per erase block by packing the free and released
  sector counts into a single byte (plus a little extra for 16 sectors per
  erase block).  A device with a 64K erase block size can benefit from this
  savings by selecting a 4096 or 8192 byte logical sector size, for example.

  SMART FS Layer
  ==============

  This layer interfaces with the SMART MTD block layer to allocate / release
  logical sectors, create and destroy sector chains, and perform directory and
  file I/O operations.  Each directory and file on the volume is represented
  as a chain or "linked list" of logical sectors.  Thus the actual physical
  sectors that a give file or directory uses does not need to be contiguous
  and in fact can (and will) move around over time.  To manage the sector
  chains, the SMARTFS layer adds a "chain header" after the sector's "sector
  header".  This is a 5-byte header which contains the chain type (file or
  directory), a "next logical sector" entry and the count of bytes actually
  used within the sector.

  Files are stored in directories, which are sector chains that have a
  specific data format to track file names and "first" logical sector
  numbers.  Each file in the directory has a fixed-size "directory entry"
  that has bits to indicate if it is still active or has been deleted, file
  permission bits, first sector number, date (utc stamp), and filename.  The
  filename length is set from the CONFIG_SMARTFS_NAMLEN config value at the
  time the mksmartfs command is executed.  Changes to the
  CONFIG_SMARTFS_NAMLEN parameter will not be reflected on the volume
  unless it is reformatted.  The same is true of the sector size parameter.

  Subdirectories are supported by creating a new sector chain (of type
  directory) and creating a standard directory entry for it in it's parent
  directory.  Then files and additional sub-directories can be added to
  that directory chain.  As such, each directory on the volume will occupy
  a minimum of one sector on the device.  Subdirectories can be deleted
  only if they are "empty" (i.e they reference no active entries).  There
  are no provision made for performing a recursive directory delete.

  New files and subdirectories can be added to a directory without needing
  to copy and release the original directory sector.  This is done by
  writing only the new entry data to the sector and ignoring the "bytes
  used" field of the chain header for directories.  Updates (modifying
  existing data) or appending to a sector for regular files requires copying
  the file data to a new sector and releasing the old one.

SMARTFS organization
====================

  The following example assumes 2 logical blocks per FLASH erase block.  The
  actual relationship is determined by the FLASH geometry reported by the MTD
  driver.

  ERASE LOGICAL                   Sectors begin with a sector header.  Sectors may
  BLOCK SECTOR      CONTENTS      be marked as "released," pending garbage collection
    n   2*n     --+---------------+
       Sector Hdr |LLLLLLLLLLLLLLL| Logical sector number (2 bytes)
                  |QQQQQQQQQQQQQQQ| Sequence number (2 bytes)
                  |SSSSSSSSSSSSSSS| Status bits (1 byte)
                  +---------------+
           FS Hdr |TTTTTTTTTTTTTTT| Sector Type (dir or file) (1 byte)
                  |NNNNNNNNNNNNNNN| Number of next logical sector in chain
                  |UUUUUUUUUUUUUUU| Number of bytes used in this sector
                  |               |
                  |               |
                  | (Sector Data) |
                  |               |
                  |               |
        2*n+1   --+---------------+
       Sector Hdr |LLLLLLLLLLLLLLL| Logical sector number (2 bytes)
                  |QQQQQQQQQQQQQQQ| Sequence number (2 bytes)
                  |SSSSSSSSSSSSSSS| Status bits (1 byte)
                  +---------------+
           FS Hdr |TTTTTTTTTTTTTTT| Sector Type (dir or file) (1 byte)
                  |NNNNNNNNNNNNNNN| Number of next logical sector in chain
                  |UUUUUUUUUUUUUUU| Number of bytes used in this sector
                  |               |
                  |               |
                  | (Sector Data) |
                  |               |
                  |               |
   n+1  2*(n+1) --+---------------+
       Sector Hdr |LLLLLLLLLLLLLLL| Logical sector number (2 bytes)
                  |QQQQQQQQQQQQQQQ| Sequence number (2 bytes)
                  |SSSSSSSSSSSSSSS| Status bits (1 byte)
                  +---------------+
           FS Hdr |TTTTTTTTTTTTTTT| Sector Type (dir or file) (1 byte)
                  |NNNNNNNNNNNNNNN| Number of next logical sector in chain
                  |UUUUUUUUUUUUUUU| Number of bytes used in this sector
                  |               |
                  |               |
                  | (Sector Data) |
                  |               |
                  |               |
                --+---------------+


Headers
=======
  SECTOR HEADER:
    Each sector contains a header (currently 5 bytes) for identifying the
    status of the sector.  The header contains the sector's logical sector
    number mapping, an incrementing sequence number to manage changes to
    logical sector data, and sector flags (committed, released, version, etc.).
    At the block level, there is no notion of sector chaining, only
    allocated sectors within erase blocks.

  FORMAT HEADER:
    Contains information regarding the format on the volume, including
    a format signature, formatted block size, name length within the directory
    chains, etc.

  CHAIN HEADER:
    The file system header (next 5 bytes) tracks file and directory sector
    chains and actual sector usage (number of bytes that are valid in the
    sector).  Also indicates the type of chain (file or directory).

Multiple Mount Points
=====================

  Typically, a volume contains a single root directory entry (logical sector
  number 1) and all files and subdirectories are "children" of that root
  directory.  This is a traditional scheme and allows the volume to
  be mounted in a single location within the VFS.  As a configuration
  option, when the volume is formatted via the mksmartfs command, multiple
  root directory entries can be created instead.  The number of entries to
  be created is an added parameter to the mksmartfs command in this
  configuration.

  When this option has been enabled in the configuration and specified
  during the format, then the volume will have multiple root directories
  and can support a mount point in the VFS for each.  In this mode,
  the device entries reported in the /dev directory will have a directory
  number postfixed to the name, such as:

    /dev/smart0d1
    /dev/smart0d2
    /dev/smart1p1d1
    /dev/smart1p2d2
    etc.

  Each device entry can then be mounted at different locations, such as:

    /dev/smart0d1 --> /usr
    /dev/smart0d2 --> /home
    etc.

  Using multiple mount points is slightly different from using partitions
  on the volume in that each mount point has the potential to use the
  entire space on the volume vs. having a pre-allocated reservation of
  space defined by the partition sizes.  Also, all files and directories
  of all mount-points will be physically "mixed in" with data from the
  other mount-points (though files from one will never logically "appear"
  in the others).  Each directory structure is isolated from the others,
  they simply share the same physical media for storage.

SMARTFS Limitations
===================

This implementation has several limitations that you should be aware
before opting to use SMARTFS:

1. There is currently no FLASH bad-block management code.  The reason for
   this is that the FS was geared for Serial NOR FLASH parts.  To use
   SMARTFS with a NAND FLASH, bad block management would need to be added,
   along with a few minor changes to eliminate single bit writes to release
   a sector, etc.

2. The implementation can support CRC-8 or CRC-16 error detection, and can
   relocate a failed write operation to a new sector.  However with no bad
   block management implementation, the code will continue it attempts at
   using failing block / sector, reducing efficiency and possibly successfully
   saving data in a block with questionable integrity.

3. The released-sector garbage collection process occurs only during a write
   when there are no free FLASH sectors.  Thus, occasionally, file writing
   may take a long time.  This typically isn't noticeable unless the volume
   is very full and multiple copy / erase cycles must be performed to
   complete the garbage collection.

4. The total number of logical sectors on the device must be 65534 or less.
   The number of logical sectors is based on the total device / partition
   size and the selected sector size.  For larger flash parts, a larger
   sector size would need to be used to meet this requirement. Creating a
   geometry which results in 65536 sectors (a 32MByte FLASH with 512 byte
   logical sector, for example) will cause the code to automatically reduce
   the total sector count to 65534, thus "wasting" the last two logical
   sectors on the device (they will never be used).

   This restriction exists because:

   a. The logical sector number is a 16-bit field (i.e. 65535 is the max).
   b. Logical sector number 65535 (0xFFFF) is reserved as this is typically
      the "erased state" of the FLASH.

ioctls
======

  BIOC_LLFORMAT
    Performs a SMART low-level format on the volume.  This erases the volume
    and writes the FORMAT HEADER to the first physical sector on the volume.

  BIOC_GETFORMAT
    Returns information about the format found on the volume during the
    "scan" operation which is performed when the volume is mounted.

  BIOC_ALLOCSECT
    Allocates a logical sector on the device.

  BIOC_FREESECT
    Frees a logical sector that had been previously allocated.  This
    causes the sector to be marked as "released" and possibly causes the
    erase block to be erased if it is the last active sector in the
    it's erase block.

  BIOC_READSECT
    Reads data from a logical sector.  This uses a structure to identify
    the offset and count of data to be read.

  BIOC_WRITESECT
    Writes data to a logical sector.  This uses a structure to identify
    the offset and count of data to be written.  May cause a logical
    sector to be physically relocated and may cause garbage collection
    if needed when moving data to a new physical sector.


Things to Do
============

- Add file permission checking to open / read / write routines.
- Add reporting of actual FLASH usage for directories (each directory
  occupies one or more physical sectors, yet the size is reported as
  zero for directories).