Shared object that supports the Power-Safe filesystem (QNX Neutrino)
driver … qnx6 qnx6_options… &
- Control which users (if any) can suspend the taking of snapshots (via a flag in the DCMD_FSYS_FILEFLAGS devctl() command). The default is root.
- 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:
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.
- 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.
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.
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
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.
- 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.
- 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.
- 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.
- 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.
- 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.