Re: Mountable filesystem image
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.
http://axfs.sourceforge.net/
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.
Cheers, Brendan.
Reply to: