PPS maintains its objects in memory while it is running. It will, as required:
|
The underlying persistent storage used by PPS relies on a reliable filesystem, such as:
If you need to persist an object to specialized hardware, such as a small NVRAM, which does not support a file system, you can create your own client which subscribes to the a PPS object to be saved. On each object change, PPS will notify your client, allowing the client to update the NVRAM in real time.
The persistence directory where PPS objects are stored uses exactly the same directory hierarchy as the PPS root directory. Object persistence is, therefore, limited by the capabilities of the underlying persistence filesystem: its support for path and filename lengths, and directory nesting limits.
For example, the QNX Neutrino NFS server supports a maximum nesting depth of 15 levels. This limit also applies to PPS using this service.
On shutdown, PPS always saves any modified objects to a persistent filesystem. You can also force PPS to save an object at any time by calling fsync() on the object.
When PPS saves to a persistent filesystem, it saves every object to its own file, in a directory hierarchy that reproduces the hierarchy of the PPS object tree. For example, with a default configuration, the PPS object /pps/foo/bar is stored at /var>pps/foo/bar.
The default location for the PPS directory is /var/pps. You can use the PPS -p option to change this location.
|
When PPS starts up, it immediately builds the directory hierarchy from the encoded filenames on the persistent filesystem. In its default configuration, PPS defers loading the objects in the directories until first access to one of the files. This access could be an open() call on a PPS object, or a readdir() call on the PPS directory.
You can use the -l option on startup to have PPS load directory and object names but not the object contents, or load directories, objects and object contents. For more information, see “Running PPS” in the chapter QNX PPS Service.