DBFS(4)DBFS(4)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, mount‐
point 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 addi‐
tional 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 when‐
ever 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 ALSOmemfs(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)