A LoggingFileSystem is a FileSystem that writes all data in an append-only log.

There are at least three LFS implementations:

	1. Sprite LFS
	1. Berkeley LFS
	1. LinLogFS (formerly dtfs)

and they are all deeply flawed. A logging FS design naturally decomposes into at least three modules on two different layers. The lower layer manages log segments on disk while the higher layer interprets the content of the segments as a tree of index nodes, or inodes. LinLogFS has only one layer since it uses physical addresses (instead of segment addresses) to point to inodes. This is ostensibly done "for speed" despite the fact that speed was explicitly rejected as a design criterion for LinLogFS (or at least, that's what the design documents claim). The fact that LinLogFS only has one layer forces it to use all kinds of tricks to implement archiving of the filesystem. What would be a trivial task has become a convoluted list of "features" that can never manage to do what people want done.

Contributor: RichardKulisz
----
What happens when the disk fills up?

When the disk is full, you start writing the really old stuff to tertiary storage. PlanNineFromBellLabs used such a policy. Every few years they would upgrade their media, vastly increasing capacity. By the time their laserdisc jukebox got full, it was time to buy a new jukebox with vastly larger capacity anyways.

If you really have to, you can institute a garbage collection policy such that object versions older than such and such are garbage. This is discussed in GarbageCollectionUnderVersioning

----

Append-only logging file systems are attractive for WORM media such as CD-RW drives.

Circular-buffer logging file systems are attractive for Flash, SecureDigital, MMC, or other media with limited write cycles, because these kinds of filesystems can guarantee perfect wear leveling.

----

See also JournalingFileSystem