Shared object that supports the Power-Safe filesystem (QNX Neutrino)
Syntax:
driver … qnx6 qnx6_options… &
Options:
The driver is any of the devb-* drivers,
and qnx6_options is one or more of the following, separated by commas:
- alignio
- Attempt to align all reads and writes in sizes and offsets of the filesystem block size.
- alimit=amount
- Set the low free space watermark, in blocks.
- crypto=enable|disable
- Enable or disable encryption support (disabled by default).
In order to use encryption, you must have formatted the filesystem with the -E option for
mkqnx6fs.
Use
fsencrypt
to manage the encryption.
- hold=allow|root|deny
- Control which users (if any) can suspend the taking of snapshots
(via a flag in the
DCMD_FSYS_FILE_FLAGS
devctl() command).
The default is root.
- overalloc
- Enable a block overallocation heuristic for small file writes.
- snapshot=freq
- Set the frequency of automatic snapshots; the default is
10 seconds.
A filesystem snapshot is explicitly made when you call sync()
or fsync(), or from this periodic timer.
- sync=mode
- Specify the required disk synchronization capability.
The mode mode must be one of the following:
- mandatory (the default) — the drive must support
synchronization to allow a filesystem to be mounted read/write.
If it doesn't, the
mount
fails and returns EROFS.
A read-only mount (mount -r) can always be performed on
any device.
- optional — attempt synchronization, but ignore any
error if the drive doesn't support such an operation.
The driver might be incorrectly advertising the capabilities, or the
physical media might not require explicit synchronization (write-through).
- none — never issue a synchronization command to
the disk, and don't drain dirty blocks from the filesystem cache
(until an explicit
umount).
This mode is suitable only for use with a UPS.
CAUTION:
If the drive doesn't support synchronizing,
fs-qnx6.so
can't guarantee that the filesystem is power-safe.
You can use the
sync option to override this requirement
at your own risk.
Before using this filesystem on devices — such as USB/Flash
devices — other than traditional rotating hard disk drive media,
check to make sure that your device meets the filesystem's requirements.
For more information, see
"Required properties of the device,"
below.
- trim=disable|enable|discard
- Disable or enable support for TRIM, or use discard instead.
A managed NAND block device can't overwrite in-place and has no idea of whether content in
a block is even valid or meaningful to a mounted filesystem.
So the management layers have no choice but to preserve all
written content, which can be a lot of wear-leveling overhead if in fact
those blocks belonged to say a deleted file, or if the partition was freshly formatted.
The TRIM command is thus a hint to the managed NAND device from the
filesystem that certain sectors are no longer live and can be discarded
(i.e., the content doesn't have to be preserved or copied by wear-leveling, and/or
logical blocks can be erased rather than be reclaimed from elsewhere).
Using the discard option gives better performance than enabling trim.
When the filesystem tells the driver to discard a set of blocks, the driver simply marks them as discarded
and returns, queuing them up for garbage collection later.
If the filesystem requests the driver to trim a set of blocks, they're cleaned immediately, which may result in
heavy disk I/O, depending on the current state of the system.
In the end they do the same thing, just with different timing.
Note:
SSDs don't support the discard option.
Description:
The fs-qnx6.so shared object provides support for
Power-Safe (copy-on-write/snapshot) filesystems.
It's automatically loaded by the devb-* drivers when mounting a
Power-Safe filesystem.
Note:
This filesystem uses UTF-8 encoding for presentation of its filenames;
attempts to specify a filename not using UTF-8 encoding will fail
(with an error of EILSEQ).
Required properties of the device
The Power-Safe filesystem was designed for and is intended for
traditional rotating hard disk drive media.
It operates by moving the on-disk filesystem state
from one stable view to another stable view using copy-on-write (COW)
to relocate modified blocks.
To finalize this transition, all dirty
blocks involved in the new view must be committed to persistent storage,
and then a new filesystem superblock/root referencing the relocated
blocks is committed.
This provides power-safe robustness, because at
any point in time either the old version is completely accessible or
the new version is completely accessible (with no live data being
overwritten in between).
Thus to mount as read-write on a given device, that
device must have the following properties:
- one of the following:
- The device may buffer write data for performance reasons, and the
return from a WRITE may not necessarily indicate the data is committed to
permanent storage.
But such a device must implement a FLUSH/SYNC
command that forces any cached or buffered write data to persistent
storage, and doesn't return until it's guaranteed that all data is
stable across a power-loss.
or:
- The device doesn't buffer write data, and operates in a strict
write-through manner, where return from a WRITE is a guarantee that the
data was immediately committed to persistent storage.
Such a device doesn't require an additional FLUSH/SYNC command.
- and both of the following:
- The action of writing to one data region (an advertised device
sector) can in no way damage the contents of any other region, even
under conditions such as power-loss, vibration, temperature, etc.
and:
- Data that has previously been reported as committed to persistent
storage remains stable until explicitly overwritten.
The device may implement facilities such as bad-block remapping or
wear-leveling to support this requirement, provided that such
activity never causes loss of persistent data, even under conditions
such as power-loss, etc.
Summary of filesystem commands
The following table shows the shared objects and related commands for the filesystems:
a Read-only.
b Not usually necessary.
For more information, see the
Filesystems
chapter of the System Architecture guide.