FS on flash (initrd, JFFS, ...)

FS on flash (initrd, JFFS, ...)

[Goddeeris Frederic]

Hi,

Could somebody give me some advise on what filesystems to use on my embedded
Linux platform?

This is my current setup that I have working now: I have the compressed
image of the kernel (+/- 0.5 MB) and a separate initrd image (+/- 1.1 MB)
that contains all needed files to boot and work (using BusyBox and TinyLog
in). I use PPCBoot. Then I have JFFS mounted on a MTD partition for
state-information and small log-files. I have a different initrd-image
because PPCBoot supports it. I need to be able to upgrade the applications
and/or the kernel remotely.

After I have this working, I need to decide how to organize everything for
the final platform. I have multiple questions:

1. When applications are started from the initrd, is it executed in place or
is it loaded again in RAM?

2. Can Linux boot from a JFFS (or any other like CRAMFS) or is a Randisk the
only option?

3. JFFS blocks while performing garbage collection. I suppose it is only the
applications/threads that are working with the files on the JFFS that are
blocked or does this garbage collection take a lot of CPU power so that also
other processes/threads are affected?

4. Any other FS than OFFS that I need to consider for storing state-info and
logfiles?

5. JFFS is stable?

6. Is JFFS2 fit for use in a product yet?

  Thanks a lot!
  Frederic


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: FS on flash (initrd, JFFS, ...)

[Adrian Cox]

Goddeeris Frederic wrote:


> 2. Can Linux boot from a JFFS (or any other like CRAMFS) or is a Randisk the
> only option?


I've set up a board with root on JFFS2. The procedure in the HOWTO for
JFFS just worked.


> 3. JFFS blocks while performing garbage collection. I suppose it is only the
> applications/threads that are working with the files on the JFFS that are
> blocked or does this garbage collection take a lot of CPU power so that also
> other processes/threads are affected?


The longest part of the process is erasing blocks, which isn't CPU
intensive. This will depend a lot on your application.


> 5. JFFS is stable?


Stable, but with known deadlocks as a result of design problems.


> 6. Is JFFS2 fit for use in a product yet?


I'd say JFFS2 is a lot safer for use in the field, because it doesn't
have the deadlocks that JFFS has. I've had one JFFS2 filesystem
destroyed by a broken driver which wrote over random kernel memory, but
it's robust against other problems.

That is the real risk of an FFS against an initrd. The initrd is much
less likely to be overwritten by a bad driver or application, and makes
it much easier to have a "return to factory settings" option



--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/