FAL/TFFS/FDC/RDC - Frequently Asked Questions

Questions: General:

1. What is the footprint?
2. Which OSs can the filestack be used with?
3. How is the performance?
4. What is the maximum disk size supported?

Questions: FDC (flash disk controller):

1. How much media storage overhead does FDC require?
2. What is the difference between NOR and NAND flash devices?
3. Which types of flash devices are supported?
4. Which flash device drivers are available?
5. Is it possible to use other file systems on top of FDC?
6. What is interleaving?
7. What is wear leveling?
8. What is reclaiming?
9. When is reclaiming done?

Questions: RDC (RAM disk controller):

1. How much media storage overhead does RDC require?

Questions: TFFS (transaction flash filesystem):

1. How much media storage overhead does TFFS require?
2. Can time stamping on files be achieved with TFFS?
3. Are there any plans for host PCMCIA support for TFFS?
4. What is the difference between TFFS version 1 and 2?
5. Using TFFS with 3rd party disk controllers

Questions: FAL (File abstraction layer):

1. How much media storage overhead does FAL require?

Answers: General:

1. What is the footprint?

This may of course depend a little bit on the CPU type, but for a 32 bit PowerPC the figures are (approximate figures below include debugging code):

ROM requirements (code, const data):
FDC: 20KB
RDC: 7KB
FAL: 4KB
TFFS: 26KB

RAM requirements (un-initialized/initialized data):
Main contribution to data use (RAM) is the FDC mapping table (see FDC doc on RAM usage), and with TFFS one cache block (typically 512 bytes) for each file opened. This data is taken from the heap. Un-initialized/initialized data can be neglected compared to this.

Stack usage has been carefully considered throughout the design, but not measured. It would also normally vary with CPU type.

2. Which OSes can the filestack be used with?

It can be used with any OS we know of. In order to be used in a multi-threading/processing environment, some small OS dependent protection glue functions must be provided.

3. How is the performance?

Flash media:

It is impossible to describe the performance in matters of KB/second, since it obviously depends on the architecture, media, driver etc. 

The performance depends a bit on how much of the flash disk is in use in your system, the higher percentage in use, the more often reclaiming has to be done, and the slower it gets. With a clean partition, we have experienced write performance of appr. 1/2 - 1/3 compared to just using the flash driver directly for writing raw data.

As an example say you have a disk with 2000 blocks and 20 erase zones. If you use 50% of the disk, then you can assume that there are 1000 blocks unused by the filesystem. They may however be used by by FDC, and marked as OBSOLETE (i.e. they can be reclaimed). On average, every erase zone would then have 50 OBSOLETE blocks that can be reclaimed when an erase zone is reclaimed. If your disk was 95% filled, you only have 100 blocks left for use. Again this would mean you would only reclaim 5 obsolete blocks on AVERAGE when erasing an erase zone. Also, reclaiming an erase zone is usually faster the more obsolete blocks it has (since valid blocks must be written somewhere else in flash). Since erasing erase zones takes a considerable amount of time (up to 1-2 seconds on some flash devices, 500ms is pretty normal erase time), the act of reclaiming can be a slow process.

The numbers above are not exact, and they all depend on the use. However it can be seen that the write time increases as the disk is filled up, since more reclaiming must be done.

The worst case is when you have filled the disk completely with data. In this case you will reclaim an erase zone for every block written. A very time consuming thing in general.

NOTICE: When using a file system such as TFFS, more blocks than the block actually holding file data is modified when for instance appending data to a file (file system table info etc.). This will actually lead to multiple block writes for every block appended to a file, causing an even worse performance situation when the disk is almost full. For this reason it is recommended that the disk is dimensioned somewhat larger than needed for expected normal use.

As such, using NOR type flash media for a file system is not something to be used in hard real-time tasks, it should be used in lower priority tasks.

RAM media:

RAM media is significantly faster than flash media since it does not have to deal with all the special flash handling. For non-volatile RAM disk, there is an overhead when writing due to making transaction records and intermediate storage. This overhead reduces the write speed to approximately half of when operating in volatile mode.

4. What is the maximum disk size supported?

Theoretical maximum disk size is 2²⁸-1 blocks. The block size is configurable to 2^N where N = (5), 6, ... (typical block size is 512 bytes). However, when used on flash media, the practical limit is much less due to RAM requirements, please refer to the FDC documentation for details on this. And there are some other limits as well, mainly the 32 bit limit, ie 4GB.  

Answers: FDC (flash disk controller):

1.  How much media storage overhead does FDC require?

The main contribution to the FDC media overhead, is typically the reserved space for reclaiming. At least (and also the normal use) appr. one erase zone must be reserved for this purpose. The percentage overhead contribution due to this obviously decreases with the partition size. If you have a partition with erase zone size 64KB, then for a 1MB partition the overhead due to this is appr. 6.3%. For a 4MB partition it would be 1.6%. In addition appr. 0.5-2% is used for other administrative purposes. The exact number depends on the block, erase zone and partition sizes.

The diagnostic function will show the storage overhead percentage for a partition.

2. What is the difference between NOR and NAND flash devices?

Without going into the physical details describing the underlying technology, NOR and NAND flash devices are quite different:

• NOR devices can have their bytes written multiple times without erasing, as long as bits are not changed from 0 to 1. This is not possible with NAND, at least not more than a couple of times.

• NOR flashes are "faultless", meaning that when data is written, the same data will always be read back. With NAND devices this may not be the case, error correction code (ECC) is usually used to detect and correct bit faults.

• NOR devices are usually (but not always) random accessible, increasing random read performance.

• NAND devices are much faster to erase and write than NOR devices.

• NAND devices consume less die space, and thus the chips are generally cheaper and smaller per MB.

The two first bullets are the main reason why FDC can not use NAND devices.

3. Which types of flash devices are supported?

Only NOR devices of flash devices are supported (see topic on NOR and NAND flash). There are no immediate plans to write a NAND version of FDC.

Furthermore, only uniformly sized erase zones (i.e. denoted blocks or sections in flash device datasheets) may be used. Thus, if using a boot type device, typically with a few erase zones of other sizes than the rest of the device, those erase zones may not be used. It is perfectly OK to use such devices, just be aware of this.

NOTICE: One should always specifically make sure that there are no special limitations on how many times one can change bits from 1 to 0 without erasing. Specifically, some multilevel type NOR devices may not handle this without limitations. And some devices have errata related to this. See comment below of known problems.

Known problems: 

Spansion (former AMD) 200nm and 230nm MirrorBit process technology devices (S29GL-M, Am29LV-M, S29GL-A) have seen problems with respect to this, and started adding appl. notes and warning in datasheet on this issue during fall 2004, long after the devices were made available for full scale use. In that case, if starting using this a year earlier, checking this issue might not have helped anyway. Spansion states the problem to be solved with new 110nm process technology (S29GL-N). Tevero has made a configurable workaround for this issue, since the default flash partition layout can violate the added limitations on bit field programming.

Additional note added 02/2006: We have discovered that Spansion made further restrictions on Am29LV-M devices in October 2005 with respect to bit field programming. In reality, this causes the Am29LV-M devices to not be suitable for flash disk usage. We do have some experience with using the flash disk on that device, and have not experienced any problems. We suspect problem not to be likely to occur, since it probably is sensible to number of writes per time unit within certain flash areas. And the file system tend to spread out write operations. But still, with the added restrictions, the device is not recommended for high reliability systems. TheAm29LV-M is being phased out anyway.

4. Which flash device drivers are available?

Sorry, we do in general not provide device drivers. Usually, there is something target specific, and writing a flash device driver is usually not a big task. We may add some skeletons in the future.

We do have competence to provide drivers, but that would be as a consultancy based service.

5. Is it possible to use other file systems on top of FDC?

Yes it is. FDC is a block oriented device driver. There are however a few things that should be noted:

When the file system has finished using a block (e.g. when deleting a file), then each block not being used anymore must be marked as obsolete, in order to be reclaimable later. This will typically require a hook to be inserted in the filesystem at proper points if no such feature is provided.

Notice also that FDC ensures that every write operation to a block is recoverable. But a file system may cause an additional block to be updated when writing (for instance FAT table in DOS filesystem). This may cause potential inconsistencies if a power failure should occur at the wrong point. For this reason TFFS was designed, since a recoverable filesystem was the main requirement when designing this SW. (FAT can normally not handle this situation in a recoverable manner.)

6. What is interleaving?

Interleaving is when flash devices are placed in parallel to form flash arrays with a wider data bus. For instance two 8 bit devices may be placed in parallel to form a 16 bit device. Or two 16 bit devices may be placed in parallel to form a 32 bit device.

Although both reading and writing performance for instance is doubled when interleaving two devices, there may be a penalty in performance due to that more data may have to be reallocated when an erase zones with a lot of valid data is reclaimed.

Typically, a performance gain is probably obtained when using a limited part of the disk. Once the disk gets filled up, the reallocation of lots of data will at some point outweigh the increased write performance.

Also, a disadvantage of interleaving is that the reserved area for reclaiming (appr. one erase zone) will increase in size, and thus more bytes are wasted on overhead.

The actual handling of interleaving is done in the device driver.

7. What is wear leveling?

Flash devices usually have a physical limit on how many times an erase zone (flash block or sector) can be erased. For instance FDC may be used with a flash disk system (e.g. TFFS), and the partition contains a lot of static data (only being read) and some data being updated frequently. The erase zones holding the static data, will never be erased, whereas some erase zones will be erased frequently. In order to extend the flash device lifetime, the static data can be moved every now and then to those erase zones that have been erased most frequently. This is called wear leveling. FDC supports wear leveling.

8. What is reclaiming?

When a block has been in use and no longer is used, it must be made obsolete. However, an obsolete block can not be reused until the erase zone it resides in is erased. The process of making obsolete blocks reusable, is called reclaiming, and is one of the more complex parts of FDC. Reclaiming also has to consider wear leveling, in order to move static blocks around every now and then.

9. When is reclaiming done?

FDC will initiate auto-reclaim in any block write operation, if no unused blocks are available. In addition, a system may implement some sort of background reclaiming, in order to provide improved write speed on average. For most normal use, the automatic reclaiming is sufficient.

Answers: RDC (RAM disk controller):

1. How much media storage overhead does RDC require?

In volatile mode, just a few bytes for partition info. In non-volatile mode, one bit overhead for every block in the partition in addition. In other words, RDC has very little overhead.

Answers: TFFS (transaction flash filesystem):

1. How much media storage overhead does TFFS require?

Every file or directory has a 32 byte (TFFS version 1) or 64 byte (TFFS version 2) overhead for attribute and name storage. In addition 4 bytes are reserved for every block to make up the block allocation table (BAT). 2 blocks for every disk are used for other system purposes.

The diagnostic function will show the storage overhead percentage for a disk.

2. Can time stamping on files be achieved with TFFS?

As of TFFS version 2, basic support of time stamping has been supported (optionally enabled). TFFS version 1 does not support time stamping. This basic time stamping includes create time for files and directories, as well as modified time for files. Modified time are either updated when closing file or if explicitly specified from the application.

If the system requires time stamping and using TFFS version 1, it is suggested that this is included by reserving some bytes in all files in FAL. This adaptation should be fairly straightforward, although not optimal. In general, upgrade to TFFS version 2 is recommended.

3. Are there any plans for host PCMCIA support for TFFS?

If using TFFS on removable media, it could be convenient to be able to have some sort of PCMCIA application SW (for instance on Windows/Linux) in order to be able to access files from a host computer.

Currently, there are no plans for implementing this, although this may change if a strong need occurs.

4. What is the difference between TFFS version 1 and 2?

The disk format layout in TFFS version 2 is slightly different compared to version 1 in order to support time stamping.

In addition, TFFS version 2 has changed recovery handling a bit in order to ease use with 3rd party standard controllers. SW supporting TFFS version 2 layout, can still use TFFS version 1 layout, but recovery handling when going from version 1 to version 2 SW is not 100% failsafe. This is never a problem, if the SW upgrade can be done in a controlled manner, since there will not be any transactions to recover first time with new SW. Some consideration due to this may have to be given if upgrading. 

5. Using TFFS with 3rd party disk controllers

It is possible to use TFFS as a fault safe file system with 3rd party disk controllers. With TFFS version 2, it has been made a bit easier to adapt to a generic disk controller, but Tevero AS does currently not have any other controllers than RDC and FDC for sale. The adaptation is up to a customer.

Answers: FAL (file abstraction layer):

1. How much media storage overhead do FAL require?

FAL does not use any space on the storage media.