AXFS: a compressed, execute-in-place filesystem
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 | |
---|---|
Kernel | Filesystems/Flash |
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.
Posted Sep 8, 2008 17:37 UTC (Mon)
by mcortese (guest, #52099)
[Link]
Why XIP doesn't get so much use with Linux...
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)?
execute-in-place with Ext2