Request a defragmentation operation on the .filetable for the ETFS
filesystem. The background processing of the ETFS filesystem does
its own defragmenting as needed. This option lets you force it to happen on
demand.

-e

Erase the device. For NAND flash,
factory-marked bad blocks aren't erased.
Blocks that become bad during normal use
(worn-out blocks) are also skipped during the erasing.

-f

Erase as in -e, then format an
empty filesystem. Don't use this option with -w, since
-w assumes an
erased partition with no filesystem.

-i

Print info about the filesystem. See the “Description” below.

-rfile

Read all data from the device and save it in the specified file.
The data is saved as a series of transactions.
This data can be written to another flash part as long
as that part has the same:

cluster size

block size (number of clusters in a block)

The data format is endian-neutral and free of any device-specific
characteristics such as how it stores CRCs or ECCs. You can now read and
write filesystems across different classes of devices, for example for NAND
and RAM.

-Rfile

Read all data from the device, including blank or erased blocks, and
save it in the specified file.
This is the raw version of -r option.

-s

Stop the filesystem on the device.

-S

Similar to -s, but wait for the filesystem to stop before returning.

-wfile

Write transactions from the specified
file to the device. This transaction file
can be created by reading it from this or
another device via the -r option of
etfsctl or by the mketfs utility.
The transactions are block-location-independent on the
device. This allows bulk programming of devices with
bad blocks in any location. The only requirement
is that enough good blocks should be available to hold all transactions.

-Wfile

Write transactions from the specified file to the device. Also, copy any
blank or erased blocks. This is a raw version of the -w option.

The etfsctl utility is used to manage an
embedded transaction filesystem (ETFS).
The utility interacts with the running filesystem
using devctl() messages.
Using etfsctl, you can erase and format a
partition, read or write an
entire transaction log (and thus its entire filesystem) from or
to the device, stop the filesystem, make it continue or get statistical
information.

Options are processed from left to right in order. The first option must be a -d device where:

/dev/etfs1

The raw partition for user extensions (such as boot images).

/dev/etfs2

The filesystem partition for etfs files.

The raw partition is used for user extensions, such as boot images,
and is always at the
start of the device. It may be zero bytes long if you don't need it.
The filesystem partition consists of a series of transactions that
together form a filesystem. You can use the -r option to
read the transactions from the device and save them
to a regular file, typically on another filesystem.
You can then use the -w option to write
this transaction log to another ETFS filesystem.

When writing, you must erase the filesystem
first; failure to do so corrupts the data on the device.

The -w option is most often used to write
transaction logs created by the mketfs utility.

You can request the filesystem to stop accepting new open
requests by using the -s or -S option.
Once the last file currently open by any
application is closed, the filesystem enters the stopped state.
A filesystem partition must be stopped in order for you to
write a transaction log to it. You can start the
filesystem again using the -c option.

The -i option provides useful statistical information about a
running filesystem. This option is so common that it
assumes /dev/etfs2, thus saving you from having to
enter the -d option before it. The information is
displayed in following groups:

Number of mining operations to recover dead space in a block.
This is how inactive clusters create filthy blocks, which become clean after
being erased.

Copy

Number of block-copy operations. Copies occur two ways:
the first way is a read in a block that has a soft ECC error,
which is an indication that the block
is getting weak. The block is copied to a new fresh
block and the block with the ECC error is erased.
In the second way, a block with a low erase count is
forced into service by copying its data to a new
block and erasing and putting this block into service.