Read Only FS

Hello,

I am working on an Assabet platform. My application will have a
significant part of the root filesystem mounted as read-only. I am thinking about installing it as romfs, which I think should be faster than JFFS2. Am I right?

Another question is wether romfs runs over MTD or it has its own access layer.

Thank you very much

three main choices:

romfs, cramfs, jffs2

romfs is uncompressed and so does not need to decompress.

cramfs is compressed and indexed, and so has shorter boot time

jffs2 is compressed but must do a full scan on bootup. It can be read/write.

Consider that flash reads may actually take longer than decompression depending on your hardware. I'd recommend a single jffs2 partition for most applications. This is the best use of a small amount of flash. Mount it readonly most of the time if you like and have some way to snapshot the current config data that remounts read-write, saves, and then remounts read-only. I have often made /var ramfs with /tmp -> /var/tmp, and /dev -> /var/dev so that writes can happen there. Then the bootup script fully populate /var.

Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Having a large romfs and then a relatively small jffs2 will make it boot faster, because the jffs2 scan obviously doesn't have as much to do. But you won't get the wear levelling - obviously the R/W bits are then limited to the area of flash that you partitioned for jffs2.

romfs will work happily on /dev/mtdblock<n> devices, either the full CONFIG_MTD_BLOCK device which would also allow you to update the contents (as long as it's not mounted at the time, of course) or the smaller CONFIG_MTD_BLOCK_RO module which provides the same device, just without write functionality.

--
dwmw2

Hi All

First:
I have noticed that when I mount a jffs2 FS(created with mkfs.jffs2) for the first time and look at the output of the df command, I see that "Use%" field slowly rise to 100% and then it drops back to ~15% and then it stays there. During this rise I also noticed that kupdate was eating alot of CPU(~80%)

Is this normal?

Second:
I have been playing with compression a bit. I changed the compress order so that RTIME is tried before ZLIB and this is what I got:

                     zlib            rtime
RootFS image size    7582088 bytes   9295044 bytes
mount time           10 sek          10 sek

The system also feels a bit faster with RTIME than ZLIB when execute programs like ls, du. Is RTIME faster to decompress data than ZLIB or is it just in my mind? :-) I am on a custom MPC860 board 80 MHz.

Is there any point to have a config option for preferred compression algorithm order?

Joakim

The first time it's mounted, all the blocks need to be erased and formatted correctly. That's done in the context of kupdated. The Use% field is high because the blocks are being taken out of the list of available blocks - we should probably fix that.

Probably not. If you want rtime first you might as well just omit zlib completely. And yes, rtime will be faster.

--
dwmw2

Hi again

Does JFFS2 erase the blocks that are already erased? I also noticed that an umount hangs until kupdate is finished, should it? Is it safe to power cycle the board during this initial formating?

OK, if I am the only one interested in this I agree. I will just edit the sources to my needs.

Jocke

Yes, because they might not be _completely_ erased - unless they have a cleanmarker node at the beginning, then it's possible that they're only partly-erased. So it erases them again, just to make sure.

There's no real reason for it to do so - can you get a backtrace (SysRq-T) and find out what it's waiting for? That should be fixable.

Yes. The formatting is done specifically to make sure it's safe to power cycle at any time.

--
dwmw2

OK, here it is:

root@localhost:~# umount /jffs2/
SysRq: Show State

free sibling

  task             PC    stack   pid father child younger older
init      S 0FF86418     0     1      0    90  (NOTLB)         
keventd   S 00000000     0     2      1        (L-TLB)       3
kswapd    S 00000000     0     3      1        (L-TLB)       4     2
kreclaimd  S 00000000     0     4      1        (L-TLB)       5     3
bdflush   S 00000000     4     5      1        (L-TLB)       6     4 
kupdate   R current      0     6      1        (L-TLB)       7     5
mtdblockd  S 00000000    12     7      1        (L-TLB)       8     6
rpciod    S 00000000     0     8      1        (L-TLB)      66     7 
syslogd   S 0FF86418     0    66      1        (NOTLB)      68     8
klogd     R 0FF7EB04     0    68      1        (NOTLB)      73    66
inetd     S 0FF86418     0    73      1        (NOTLB)      74    68

bash S 0FEC35AC 192 74 1 93 (NOTLB) 90 73
jffs2_gcd_mtd4 S 00000000 0 90 1 (L-TLB) 74
umount D 0FF8CA54 0 93 74 (NOTLB)

Jocke

Why are there no call traces in that?

--
dwmw2

Don't know. This is the output I get after enabling SysReq in kernel and sending a BREAK-t on the serial port. I am using MV's HHL 2.0.0 kernel for a MPC860

Jocke

Hmmm. OK, try working out where the umount process is sleeping. Where's 0x0FF8CA54?

--
dwmw2

hmm, this is somewhat difficult. I don't have sources handy for umount, nor is umount compiled with debug turned on.

Any pointers on how to get backtrace working?

Jocke

It's not in userspace. It'll be in the kernel.

I assume that was added in a later kernel.

--
dwmw2

Hi all

Some update I have noticed:
When I download a big tarfile, untar it, remove tarfile, reboot.
One of the initscripts does a remount and there it hangs again for some 30-60 seconds. This is our typical SW upgrade senario so it is a bit annoying.

Am I the only one seeing this?
I am running Monta Vistas HHL 2.0 MPC8xx kernel(2.4.2 based). Could this problem be local to the HHL kernel or is it a JFFS2 thing?

I am using JFFS2 CVS from around October 23

Joakim