forkb0mb.org - VM System

Anatomy of Linux Journaling File Systems

nospam@example.com (TJE) — Sun, 15 Jun 2008 18:23:31 -0400

Anatomy of Linux Journaling File Systems

In recent history, journaling file systems were viewed as an oddity and thought of primarily in terms of research. But today, a journaling file system (ext3) is the default in Linux. Discover the ideas behind journaling file systems, and learn how they provide better integrity in the face of a power failure or system crash. Learn about the various journaling file systems in use today, and peek into the next generation of journaling file systems.

You can define journaling file systems in many ways, but let's get right to the point. Journaling file systems are for people who tire of watching the boot-time fsck, or file system consistency check process. (Journaling file systems are also for anyone who likes the idea of a fault-resilient file system.) When a system using a traditional, non-journaling file system is improperly shut down, the operating system detects this and performs a consistency check using the fsck utility. This utility scans the file system (which can take a considerable amount of time) and fixes any issues that can be safely corrected. In some cases, the file system can be in such bad shape that the operating system boots into single user mode to allow the user to further the repair process.

/*
It is due to a lack of a journal that Windows must be cleanly shut down or else you risk damaging your file-systems.
*/

So, now you know for whom journaling file systems were created, but how do they obviate the need for fsck? In general, journaling file systems avoid file system corruption by maintaining a journal. The journal is a special file that logs the changes destined for the file system in a circular buffer. At periodic intervals, the journal is committed to the file system. If a crash occurs, the journal can be used as a checkpoint to recover unsaved information and avoid corrupting file system metadata.

To sum up, journaling file systems are fault-resilient file systems that use a journal to log changes before they're committed to the file system to avoid metadata corruption. But like many Linux solutions, more than one option is available to you. Let's take a short walk through journaling file system history, and then review the file systems available and how they differ.

/*
As usual, this is another excellent entry on IBM's DeveloperWorks. With my interest in file-system development, this was quite a worthwhile read.

The article also links to many other "Anatomy of..." articles, including all DeveloperWorks articles by M. Tim Jones:

Anatomy of Linux Flash File Systems

Anatomy of Real-Time Linux Architectures

Anatomy of the Linux SCSI Subsystem

Anatomy of the Linux File System

Anatomy of the Linux Networking Stack

Anatomy of the Linux Kernel

Anatomy of the Linux Slab Allocator

Anatomy of Linux Synchronization Methods

Linux /proc/sys/vm/drop_caches

nospam@example.com (TJE) — Tue, 18 Sep 2007 23:13:49 -0400

Linux /proc/sys/vm/drop_caches

Free pagecache:
echo 1 > /proc/sys/vm/drop_caches

Free dentries and inodes:
echo 2 > /proc/sys/vm/drop_caches

Free pagecache, dentries and inodes:
echo 3 > /proc/sys/vm/drop_caches

It is recommended that the user run sync(1) first. This tunable was added in kernel 2.6.16.

/*
I paraphrased most of the info from the page linked, but this is a pretty nifty trick. Too bad this wasn't in 2.6.9-HUGEMEM, it would likely have been of huge benefit being in 32-bit mode with a lot of RAM. I was running 32 GB of RAM on 32-bit OS (64-bit hardware), and kept running out of free chunks in many different areas, and fragmentation was horrible. This might have cleared that up.
*/

Anatomy of the Linux Slab Allocator

nospam@example.com (TJE) — Fri, 18 May 2007 10:31:32 -0400

Anatomy of the Linux Slab Allocator

/*
Another great IBM DeveloperWorks article. This one covers the memory management system in Linux 2.6.21.
*/

Understanding Virtual Memory

nospam@example.com (TJE) — Wed, 16 May 2007 14:51:46 -0400

Understanding Virtual Memory

/*
This is a RedHat Magazine article. It's a little out-dated, covering RHEL 3.x with it's 2.4 series kernel. This is still an interesting read as it gives good coverage from the OS level of how RHEL manages it's memory system.
*/

AmigaOS 4.0 New Memory System Revisited

nospam@example.com (TJE) — Tue, 18 Jul 2006 20:48:04 -0400

AmigaOS 4.0 New Memory System Revisited

[Virtual Address Space Allocation]
For one, all free resource blocks are held in space-segregated lists, i.e. there is a list for each power-of-two resource group. This makes allocations a lot faster by providing an upper and lower bound for a search. For example, if you want to allocate a block of 2^10 bytes, you can basically skip searching any block below 2^10 bytes in size simply because it won't fit. Similarly, you don't need to search for blocks that are larger than, say, twice the size of the block, since there might still be blocks of a size near to what we need. Size-segregated free lists help narrow down the search, making the search itself faster and the result better in terms of fragmentation.

In addition, the resource maps use the normal object caches for accelerating "small" allocations. Most allocations are below a certain size. For example, the virtual addresses are always allocated in chunks of at least one "page" in memory (4KB). So it's common to allocate blocks of one, two, four, or eight pages. The object caches provide an easy method for keeping these common sizes, making every allocation of these sizes an exact fit, further reducing fragmentation.

/*
This is a great way to handle memory allocation, IMO. It's not quite O(1), but it's certainly faster than your average O(n) algorithms. I'd say it would be O(m/n) where 0 < m < 1 and n > 1. This should also greatly reduce external fragmentation of the VM system.
*/

[Physical Page Allocation]
The de-facto standard in allocation of physical pages is a method invented by Knuth, called the "buddy system". Basically every modern operating system uses it, and AmigaOS4.0 is no exception to that.

Buddy systems are in essence size-segregated free lists (see above). To allocate, the system searches for a free block of at least the size of the allocation. Then, if the block is too large, it's split into two even-sized blocks. These blocks are called "buddies". One block is returned to it's appropriate free list, and the other is considered further, maybe splitting it further until it's size matches that of the allocation.

/*
It appears that AmigaOS favors "best-fit" over "first fit" allocation. Generally speaking, this is the favored approach as you alleviate memory fragmentation at the expense of a few extra CPU cycles. There's nothing worse than having 30% of your physical memory free, but fragmented to the point that no block is able to serve a request.
*/