[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mountable filesystem image

On Thu, Nov 05, 2009 at 10:10:12AM +1100, Brendan Simon (eTRIX) wrote:
Jonas Smedegaard wrote:
On Wed, Nov 04, 2009 at 12:51:39PM +1100, Brendan Simon (eTRIX) wrote:
Anyone know of a filesystem image format that is mountable and writable ??

I was thinking of something along the lines of the qcow2 format for QEMU, but something that is mountable by the linux kernel.

Essentially I want an ext2/ext3 rootfs (and possibly others) filesystem image that lives on a compact flash card that the linux can mount and use inplace as filesystem. i.e. all modifications would get written back to the filesystem image.

I do not want to format and partition the CF card into ext2/ext3 partitions. I want to keep the one FAT partition and have multiple linux filesystem images as files on the FAT partition.

I am in no way expert on the subject, but just happened to stumble across the following last night, which sound exactly like the thing you are looking for: http://www.aweiler.com/linux/debianonflash.html

Great article/tutorial/howto.

The main issue seems to be wear leveling. If wear leveling is not done by the flash device, then flash filesystem (FFS) is required (e.g. JFFS2).

If the FFS only has an mtd interface, then the block2mtd driver is required. Another translation layer that will have some performance penalty, probably not too significant for most applications.

If compression is used, then any memory mapped files need to be copied to another filesystem that is not compressed (e.g. a RAM disk).

I came across an interesting filesystem called AXFS.
It is an Execute In Place (XIP) filesystem which seems to perform very
well in real world tests on embedded devices.  It also appears to have
good compression too.
It works with NOR and NAND, and has mtd and block mount interfaces .....
may not need mtd2block translation ??
I'm not sure about wear leveling.

I think XIP works well for devices with small RAM as RAM can be saved by
executing code out of Flash.  For embedded systems with large amounts of
RAM this probably not an issue.

Very impressive!

Read-only, unfortunately - according to the Feature page.

I do suspect, however, that compression may have a negative affect on wear, because when the userspace process wants to rewrite only smaller parts of a file then the filesystem recodes that into some (assumably larger) chunks.

So without actually doing the detailed math, I would assume that one would get either good wear handling + writable *or* compression (on a writable system).

Besides, Brendan didn't ask for compression or memory consumption. ;-)

Personally, I would worry most about stability. And AXFS seems young.

If on a potent machine (i.e. plenty of cpu and memory) I would use ext3 with journalling turned off. This is a heated subject, so please, before chiming in with arguments for or against, go read some of the massive public discussions and articles on the subject.

Here is a (seemingly - again, I am not an expert!) good comparison between JFFS2 and YAFFS2, which might also be interesting as a starting point for comparing with other FFS FSes: http://www.yaffs.net/comparison-yaffs-vs-jffs


 - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

Reply to: