| LOGFS(3) | Library Functions Manual | LOGFS(3) |
logfs - log-structured file system for flash devices
bind -b '#ʟ' /dev
/dev/logfsctl
/dev/logfsusers
/dev/logfsname
/dev/logfsnameboot
echo fsys name config flash-device
> /dev/logfsctl
echo fsys name format boot-area-size >
/dev/logfsctl
echo fsys name open > /dev/logfsctl
mount -Ac /dev/logfsname dir
Logfs is a driver level implementation of the Inferno log structured filesystem, a file system designed with modern flash devices (such as NAND flash) in mind. Logfs is itself hardware independent, requiring other devices to provide the physical medium. Currently only flash (3) devices are supported.
The file system maintains two storage regions on the same medium: a log-structured hierarchical file system that implements all the functionality communicable by the 9P protocol (see intro (5)), and a boot partition that offers a fixed amount of flat storage suitable for holding such things as a kernel boot image, boot parameters etc. The boot partition can be accessed and updated without understanding all but the simplest facts about the hierarchical file system, making it easy to implement boot loaders with small footprints.
The physical layout of the file system varies from medium to medium, so that the specialised features of the medium can be accounted for.
The user table is maintained in memory; there is one table, shared between all file systems supported by this driver. There is no distinction between users and groups: a user is a group with one member. The user table records a mapping between uids and unames, as well as recording the leader and members of each group. A uid is a string naming a user or group that is stored in the file system. A uname is the string naming a user or group that is used in file system protocol messages (see intro (5)). There is a distinction so that unames can be safely reused, even though uids cannot.
Configuration and control of the file systems is by writing commands to /dev/logfsctl:
The file system log may be subject to a small amount of buffering for efficiency purposes; therefore, it is necessary to unmount the file system before disconnecting the power to avoid losing recent updates. Failure to do this does not result in inconsistencies in the file system, but some recent changes will be lost. Equivalently, a wstat (5) of any file or directory, with all fields set to no change (also known as a wstat flush) will cause the log to be written to disk. Note that during a dismount, and also a wstat flush, a wstat flush is also applied to the underlying flash (3) device. Furthermore, since some buffering is used on the log, needless use of wstat flush will consume log space more rapidly than normal, although it will be recovered during the next sweep.
The log is automatically swept when space is low, so there is not normally any need to use the sweep command.
/liblogfs
/libnandfs
/emu/port/devlogfs.c
/os/port/devlogfs.c
The only medium currently supported is NAND flash. This is detected by recognising the manufacturer and device ids supplied by the status file of the flash (3) device.