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 filesys-
tem 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 popu-
lated 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 speci-
fies a sh(1) command to be run whenever the contents of the
database change. The index file is provided as a conve-
nience 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 for-
mat: 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 confu-
sion when the database is re-read. Rawdbfs can store arbi-
trary 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 stor-
age, where it is important to minimise the number of writes.
Page 1 Plan 9 (printed 4/19/24)
DBFS(4) DBFS(4)
Note that the record numbers always get their initial num-
bering 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.
Page 2 Plan 9 (printed 4/19/24)