Log-structured File System

From Wikipedia, the free encyclopedia

This is about the NetBSD file system. For the concept, see log-structured file system.

The Log-Structured File System (or LFS) is an implementation of a log-structured file system, originally developed for BSD. It was removed from FreeBSD and OpenBSD. In NetBSD, it's still present, but it appears to be no longer completely functional as of NetBSD 2.0.2, having not been maintained for many years. There has been work, however, since in the recent 3.0 branch to bring the file system back up to production standard.

[edit] Design

Most of the on-disk format of LFS is borrowed from UFS. The indirect block, inode and directory formats are almost identical. This allows well-tested UFS file system code to be re-used; current implementations of LFS replace the lower-level Berkeley FFS code in UFS with LFS code, and share the higher-level UFS code with FFS.

LFS divides the disk into segments, only one of which is active at any one time. Each segment has a header called a summary block. Each summary block contains a pointer to the next summary block, linking segments into one long chain that LFS treats as a linear log. The segments do not necessarily have to be adjacent to each other on disk; for this reason, larger segment sizes (between 384KB and 1MB) are recommended because they amortize the cost of seeking between segments.

Whenever a file or directory is changed, LFS writes to the head of this log:

1. Any changed or new data blocks.
2. Indirect blocks updated to point to (1).
3. Inodes updated to point to (2).
4. Inode map blocks updated to point at (3).

Unlike UFS, inodes in LFS do not have fixed locations. An inode map—a flat list of inode block locations—is used to track them. As with everything else, inode map blocks are also written to the log when they are changed.

When a segment is filled, LFS goes on to fill the next free or clean segment. Segments are said to be dirty if they contain live blocks, or blocks for which no newer copies exist further ahead in the log. The LFS garbage collector turns dirty segments into clean ones by copying live blocks from the dirty segment into the current segment and skipping the rest. The summary block in each segment contains a map to track live blocks.

Generally, garbage collection is delayed until there are no clean segments left; it can also be deferred for when the system is idle. Even then, only the least-dirty segments are picked for collection. This is intended to avoid the penalty of cleaning full segments when I/O bandwidth is most needed.

At a checkpoint (usually scheduled about once every 30 seconds), LFS writes the last known block locations of the inode map and the number of the current segment to a checkpoint region at a fixed place on disk. There are two such regions; LFS alternates between them each checkpoint. Once written, a checkpoint represents the last consistent snapshot of the file system. Recovery after a crash and normal mounting work the same way—the file system simply reconstructs its state from the last checkpoint and resumes logging from there.

[edit] Disadvantages

• There can be severe file fragmentation in LFS, especially for slowly-growing files or multiple simultaneous large writes. This inflicts a severe performance penalty, even though the design rationale for log-structured file systems assumes disk reads will mostly be cached away.
• LFS becomes progressively less efficient as it nears maximum capacity, when the garbage collector has to run almost constantly to make clean segments available.
• LFS does not allow snapshotting or versioning, even though both features are trivial to implement in general on log-structured file systems.

[edit] References

• Rosenblum, Mendel and Ousterhout, John K. (June 1990). "The LFS Storage Manager." Proceedings of the 1990 Summer Usenix. 315-324.
• Rosenblum, Mendel and Ousterhout, John K. (February 1992). "The Design and Implementation of a Log-Structured Filesystem." ACM Transactions on Computer Systems. 10(1). 26-52.
• Seltzer, Margo, Bostic, K., McKusick, M. and Staelin, C. (January 1993). "The Design and Implementation of the 4.4BSD Log-structured File System". Proceedings of the 1993 Winter Usenix.
• McKusick, M. et al (1996). The Design and Implementation of the 4.4BSD Operating System. Addison Wesley. ISBN 0-201-54979-4.
• J. Matthews, D. Roselli, A. Costello, R. Wang, and T. Anderson (October 1997). "Improving the Performance of Log-Structured File Systems with Adaptive Methods", Proceedings of the Sixteenth ACM SOSP.