NAME

dbfs, rawdbfs - simple database file system

SYNOPSIS

dbfs [ -abcer ] file mountpoint
rawdbfs [ -abcelx ] [ -u cmd ] file mountpoint

mountpoint/new
mountpoint/0
mountpoint/1
mountpoint/...

DESCRIPTION

Dbfs and rawdbfs both expose a simple, record-based filesystem stored in file. The -a, -b and -c options have the same meaning as the options accepted by bind(1). If the -e option is given, then file will be created if it does not already exist. The filesystem provided by both dbfs and rawdbfs is substantially the same: when started, mountpoint is populated with numbered files, one for each record found in file. A read of one of these files yields the data in the record; a write stores data in the record. A new record can be created by opening the new file; writes to this file write to the new record. The name of the new file can be discovered by using fstat in sys-stat(2). Records can be removed by removing the appropriate record file.

Rawdbfs has additional features for database use: -x causes two additional files ("index" and "stats") to appear in the mounted directory, -l specifies that a record can only be opened for writing by one process at once, and -u cmd specifies a sh(1) command to be run whenever the contents of the database change. The index file is provided as a convenience for database client applications. Once initialised (by writing an integer value to it), subsequent reads return an ever-increasing integer value. Reading the stats file returns counts of database read, write, create and delete operations as a string of four integers.

Dbfs and rawdbfs differ in the way that they store their data. Dbfs stores its records in file in a simple text format: the end of a record is indicated by an empty line. The file is completely rewritten every time a record is written. Storing records containing blank lines will lead to confusion when the database is re-read. Rawdbfs can store arbitrary data, but the format of the data storage is known only to itself. It does not rewrite the whole file on every record change, so can be more suitable for flash-based storage, where it is important to minimise the number of writes.

Note that the record numbers always get their initial numbering from the order of the records in file. You cannot assume that the filename given to a record will remain the same between runs of dbfs.

SOURCE

/appl/cmd/dbfs.b
/appl/cmd/rawdbfs.b

SEE ALSO

memfs(4), ramfile(4), calendar(1)

BUGS

Write offsets are ignored, so the maximum amount of data that can be stored in a record is ATOMICIO bytes (i.e. 8K).

There is no way to compact a file maintained by dbfs.

DBFS(4 )

Rev:  Tue Mar 31 02:42:39 GMT 2015