|
|
Subscribe / Log in / New account

AXFS: a compressed, execute-in-place filesystem

By Jonathan Corbet
August 26, 2008
Filesystems are clearly an area of high development interest at the moment; hardly a week goes by without a new filesystem release for Linux popping up on some list or other. All of this development is motivated by a number of factors, including the increasing size of storage devices and the increasing capability of solid-state storage. Beyond that, though, there is the simple fact that there is no single filesystem which is optimal for all applications. The recently-announced AXFS filesystem is a clear example of what can be done if one targets a specific use case and optimizes for that case only.

At a first impression, AXFS seems like a simple and limited filesystem. It is, for example, read-only; the AXFS developers have made no provision for changing the filesystem after it is created. Some filesystems have a great deal of code dedicated to the creation of the optimal layout of file blocks on disk; AXFS has none of that. Instead, it has a simple format which divides the media into "regions" and, almost certainly, spreads accesses across the device. There is no journaling, no logging, no snapshots, and no multi-device volume management.

What AXFS does provide is compressed storage using zlib. It is, clearly, aimed at embedded systems using flash-based storage. For such devices, a compressed filesystem can be built using the provided tools, then loaded into a minimal amount of flash on each device. It thus joins a number of other compressed filesystems - cramfs and squashfs, for example - provided for this sort of application. One interesting aspect of compressed, flash-oriented filesystems is their apparent ability to stay out of the mainline kernel. By posting AXFS for review on linux-kernel, developer Jared Hulbert may be trying to avoid a similar fate.

The feature which makes AXFS different from squashfs and cramfs is its support for execute-in-place (XIP) files. Some types of flash can be mapped directly into the processor's address space. When running programs stored on that flash, copying pages of executable code from flash into main memory seems like a bit of a waste: since that code is already addressable by the processor, why not run it from the flash? Executing code directly from flash saves RAM; it also makes things faster by eliminating the need to copy those pages into RAM at page fault time. As a result, systems using XIP tend to boot more quickly, a feature which designers (and users) of embedded systems appreciate.

Linux has had an execute in place mechanism for a few years now, but relatively few filesystems make use of it. AXFS has been designed from the beginning to facilitate XIP operation - that's its reason for existence (and the origin of the "X" in its name).

There is an additional twist, though. One would ordinarily consider compressed storage and XIP to be mutually exclusive - there is little value in mapping compressed executable code into a process's address space. To be able to executed in place, a page of code must be stored uncompressed. What makes AXFS unique is its ability to mix compressed and uncompressed pages in the same executable file. So pages which will be frequently accessed can be stored uncompressed and executed in place. Pages with infrequently-needed code or which contain initialized data can be stored compressed to save space and uncompressed at fault time.

This is a slick feature, but it is not of great use if one does not know which pages of an executable file are heavily enough used to justify storing them without compression. Trying to determine this information and manually pick the representation of each page seems like an error-prone exercise - not to mention one which would tend to create high employee turnover. So another method is needed.

To that end, AXFS provides a built-in profiling mechanism. Each AXFS filesystem is represented by a virtual file under /proc/axfs; writing "on" to that file will cause AXFS to make a note of every page fault within the filesystem. Reading that file then yields spreadsheet-like output showing, for each file, how many times each page was faulted into the page cache. Using this data, it is possible to generate an AXFS filesystem image with an optimal number of compressed pages for the target system.

Filesystems normally need a few rounds of review before they can make it into the mainline; some filesystems need rather more than that. AXFS is sufficiently simple, though, that it may find a quicker path into the kernel. So far, the comments have mostly been positive, with the biggest complaint being, perhaps, that its name is too close to that of the existing XFS filesystem. So a 2.6.28 merge for AXFS, while far from guaranteed, would appear to be not entirely out of the question.

Index entries for this article
KernelFilesystems/Flash


to post comments

Why XIP doesn't get so much use with Linux...

Posted Sep 5, 2008 0:10 UTC (Fri) by HalfMoon (guest, #3211) [Link]

XIP is less interesting now than it was a few years back. The thing is that it basically applies only to NOR flash ... but it's NAND which is getting the huge price shrinkage. I suppose folk developing ROM images could also use XIP, but that just seems to emphasize the point that the audience here doesn't seem to be one with long term growth.

A technical reason why XIP isn't as interesting lately include that the access times hurt ... it's pretty much always a lot faster to run from RAM. So you don't want XIP for frequently-used code.

There are places where XIP matters a lot, though many of them don't run Linux. Some won't even run uClinux. Any place you see microcontrollers in use, it's likely you're talking about System-On-Chip processors with integrated flash used for program memory. Things like AVR8 (and some AVR32), MSP430, PIC (sigh), ARM7TDMI, C2000 ... where 256KBytes of flash is a rather large part, as is 32KB of RAM, and a 60 MHz clock rate is pretty fast.

XIP with uClinux can be a way to keep system costs low though. If you're using only a 4 MB flash, and 16 MB of RAM, you're probably pretty close to the performance edge. Getting a few extra MBytes of working memory by using XIP can help shave dollars from your BOM.

execute-in-place with Ext2

Posted Sep 8, 2008 17:37 UTC (Mon) by mcortese (guest, #52099) [Link]

Is execute-in-place applied to ext2 worth investigating with latest notebooks that feature solid state devices as the main storage (e.g. the Asus EeePC)?


Copyright © 2008, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds