mkefs and its buildfile

The mkefs utility uses instructions in its buildfile to build a flash filesystem image file.

The mkefs utility use a buildfile similar to the buildfile mkifs uses. A mkefs buildfile is a list of attributes and files to be included in the filesystem. Its syntax is similar to the mkifs buildfile syntax (see Buildfile syntax). However, mkefs supports a different set of attributes, including the following:

Specifies the block size of the flash device being used; defaults to 64 KB. SeeBlock size below for a discussion of interleave considerations for flash devices.
Specifies the maximum size of the flash device; is used to check for overflows. The default is 4 Gbytes.
Specifies the number of spare blocks to set aside for the flash filesystem; see Spare blocks below.
Specifies the minimum size of the filesystem. If the resultant image is smaller than tsize, the image is padded out to tsize bytes. This padding creates a flash filesystem partition with room for additional files. The default is unspecified, meaning that the image won't be padded.
Note: For a complete description of the mkefs buildfile syntax and supported attributes, see the mkefs documentation in the Utilities Reference.

Here's a very simple example of a mkefs buildfile:

[block_size=128k spare_blocks=1 filter=deflate]

In this example, the attributes specify:

Block size

The only information you need to provide about the flash devices used in your system is the block size, which you specify withe the block_size attribute.

The value you should specify for the block_size attribute depends on the physical block size of the flash device (see the manufacturer's data sheet), and on how the flash device is configured in your hardware (specifically the interleave).

Use the following formula determine the value you should set for block_size:

For example, if you have a 16-bit flash interface, and are using a 16-bit flash device with a 64 KB block size, you should set block_size to 64000 (16 / 16 × 64000 = 64000).

Spare blocks

The spare_blocks attribute indicates how many blocks should be left as spare. A value of 0 indicates a “read/write” (or “write-once”) flash filesystem, whereas a value greater than 0 indicates a “read/write/reclaim” filesystem.

The default is 1 (one), but the number of spare blocks you'll need depends on the amount of writing you'll do. You should specify an odd number of spare blocks, usually 1 or 3. QNX Neutrino allocates and recovers blocks two at a time. Specifying an odd number of spare blocks ensures that read and write activity is properly distributed across blocks.

  • If you don't set aside at least one spare block (i.e. the spare_blocks attribute is 0), then the flash filesystem driver won't be able to reclaim space, and will eventually fill up.
  • Flash memory has an upper limit to the number of reads and writes it can handle during its life span. Specifying an even number of blocks can cause continuous spikes of activity on specific blocks, which may shorten the expected life span of the flash device.

The filesystem doesn't use a spare block until it's time to perform a reclaim operation. A non-spare block is then selected for “reclamation”, and the data contained in that block is coalesced into one contiguous region in the spare block. The non-spare block is then erased and becomes the new spare block. The former spare block takes the place of the reclaimed block.