Read Only FS

Read Only FS

[Jose Rodríguez Argente]

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

Re: Read Only FS

[Tim Riker]

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.

Jose Rodríguez Argente wrote:
> 
> 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
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
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.

Re: Read Only FS

[David Woodhouse]

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

Question/suggestion

[Joakim Tjernlund]

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 

Re: Question/suggestion

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> 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? 

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.


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

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

--
dwmw2

RE: Question/suggestion

[Joakim Tjernlund]

Hi again
> 
> joakim.tjernlund@lumentis.se said:
> > 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? 
> 
> 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.

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?

> 
> 
> >  Is there any point to have a config option for preferred compression
> > algorithm order?
> 
> Probably not. If you want rtime first you might as well just omit zlib 
> completely. And yes, rtime will be faster.
OK, if I am the only one interested in this I agree. I will just edit the sources to
my needs.

 Jocke
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Question/suggestion

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  Does JFFS2 erase the blocks that are already erased?

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.

> I also noticed that an umount hangs until kupdate is finished, should it?

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.

> Is it safe to power cycle the board during this initial formating? 

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

--
dwmw2

RE: Question/suggestion

[Joakim Tjernlund]

> 
> joakim.tjernlund@lumentis.se said:
> >  Does JFFS2 erase the blocks that are already erased?
> 
> 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.
> 
> > I also noticed that an umount hangs until kupdate is finished, should it?
> 
> 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.

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
> 
> > Is it safe to power cycle the board during this initial formating? 
> 
> Yes. The formatting is done specifically to make sure it's safe to power 
> cycle at any time.
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Question/suggestion

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> > 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.

> OK, here it is:

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

Why are there no call traces in that?  

--
dwmw2

RE: Question/suggestion

[Joakim Tjernlund]

> joakim.tjernlund@lumentis.se said:
> > > 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.
> 
> > OK, here it is:
> 
> > root@localhost:~# umount /jffs2/ 
> > SysRq: Show State
> 
> Why are there no call traces in that?  

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

> --
> dwmw2
> 
> 

Re: Question/suggestion

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  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 

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

--
dwmw2

RE: Question/suggestion

[Joakim Tjernlund]

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
> 
> joakim.tjernlund@lumentis.se said:
> >  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 
> 
> Hmmm. OK, try working out where the umount process is sleeping. Where's 
> 0x0FF8CA54?
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Question/suggestion

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> hmm, this is somewhat difficult. I don't have sources handy for
> umount, nor is umount compiled with debug turned on.

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

> Any pointers on how to get backtrace working? 

I assume that was added in a later kernel. 

--
dwmw2

RE: Question/suggestion

[Joakim Tjernlund]

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

> 
> 
> 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?
>