On Mon, 5 Feb 2001, Emmons, Christopher D wrote:
> I am confused over the entire ramdisk concept for embedded systems. I think
> several on this list wouldn't mind an explanation on why a large ramdisk
> (>8192k, I assume) is "insane."
> Example Scenario: I want to put a music player and a few large song files
> on my assabet. These files take up 10 megs alone without any sort of
> filesystem, etc. Now, being a novice, I see two options: (1) create a large
> ramdisk of say, 16 megs {the option I thought was a good idea} or (2) create
> several ramdisks, one with the kernel and basic OS, and another 1 or 2 for
> the files {I have no idea how I would do this if it is even practical}.
First, a ramdisk uses ram. If you have 8MB ramdisk, you loose 8MB of
precious memory. If you have 16MB ramdisk, the half of your memory is
locked down by your filesystem. This is utterly wasteful, especially since
that same data is also available in flash memory already where you're
probably copying this whole chunk of data from anyway. If one's goal was
rather to really upload such a ramdisk over the serial port then my
suggestion would be for any such person to invest his time into gardening
instead.
A ramdisk is pretty handy for testing and/or temporary/limited tasks, like
having a minimum environment to easily upload more serious stuff into the
flash by using a network link, or to mount the real filesystem via NFS, etc.
But it is quite a bad idea to run embedded systems out of a ramdisk,
especially when you have the same data in flash already!
Instead, you should use the MTD drivers to access flash data directly. If
your Assabet has only 4MB of flash, then replace them with bigger parts
(they are socketed so that's easy to do). Look at
drivers/mtd/sa1100-flash.c to see how you can partition your flash so to
leave your boot firmware in a partition of its own. Then you may use any
kind of filesystem in your flash partitions, even cramfs if compression is
required. The MTD layer has a block interface driver that can present flash
partitions just as if they were hard disk partitions. Get familiar with
this, make it work for you, and see how much free ram you then have! The
kernel is quite smart at moving what it really needs into ram, uncompressing
it on the fly if needed, and dropping unused content from ram when ram is
required by some other applications. This is simply not possible with a
ramdisk.
When you've reached that point, then you may consider another structural
level, the best I found so far, which consist of using two flash partitions:
the first one being a single flash sector long to hold your bootloader, and
the second one spaning onto the entire remaining flash using JFFS
(Journaling Flash File System). For partitions that contained compressed
filesystems before, you just need to use the loopback block interface to
access them while holding their images into the JFFS partition. Even the
kernel zImage can be stored into that partition and be booted by the
bootloader from there (John Dorsey made a patch for Compaq's bootldr to do
just that). This is how you will get the most efficient and secure usage of
your flash memory. If you still need more filesystem space then consider
bigger flash or networked filesystems.
Also note that for volatile storage purpose like /tmp you should consider
using ramfs since the flash has a limited number of write cycles.
Now PLEASE let's stop those jumbo ramdisk discussion since this is really
not the way to do things, OK?
Nicolas
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
