[ECOS] Problems with JFFS2 when mounted with < 5 sectors

[ECOS] Problems with JFFS2 when mounted with < 5 sectors

[Øyvind Harboe]

I've got a JFFS2 fs mounted with only a single sector.

In this application, there is a phase where JFFS2 is written to,
and afterwards it is protected in hardware and never changed again.

JFFS2 scores over a ROM fs, because a ROM fs is normally created
on the developer machine during compile time, whereas the JFFS2
fs can be laid out by the application in the field.

To my surprise, JFFS2 will refuse to write more files if there
are less than 5 secotors free.

Having no fear, I set JFFS2_RESERVED_BLOCKS_WRITE = 0.

Apparently this is to avoid "endless gc looping".

http://lists.infradead.org/pipermail/linux-mtd/2003-April/007437.html

If someone could shed some light on this, I would be much obliged.


I posted this to the JFFS2 mailing list as well, but so far no luck. 
Perhaps eCos people are more into the deeply embedded where JFFS2
mounted <5 sectors is more common...

http://lists.infradead.org/pipermail/linux-mtd/2003-October/008605.html




Øyvind



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Problems with JFFS2 when mounted with < 5 sectors

[Eric Donnat]

On Mon, 06 Oct 2003 14:34:19 +0200
Øyvind Harboe <oyvind.harboe@zylin.com> wrote:

> I've got a JFFS2 fs mounted with only a single sector.
> 
> In this application, there is a phase where JFFS2 is written to,
> and afterwards it is protected in hardware and never changed again.
> 
> JFFS2 scores over a ROM fs, because a ROM fs is normally created
> on the developer machine during compile time, whereas the JFFS2
> fs can be laid out by the application in the field.
> 
> To my surprise, JFFS2 will refuse to write more files if there
> are less than 5 secotors free.
> 
> Having no fear, I set JFFS2_RESERVED_BLOCKS_WRITE = 0.
> 
> Apparently this is to avoid "endless gc looping".
> 
> http://lists.infradead.org/pipermail/linux-mtd/2003-April/007437.html
> 
> If someone could shed some light on this, I would be much obliged.
> 
> 
> I posted this to the JFFS2 mailing list as well, but so far no luck. 
> Perhaps eCos people are more into the deeply embedded where JFFS2
> mounted <5 sectors is more common...
> 
> http://lists.infradead.org/pipermail/linux-mtd/2003-October/008605.html
> 

Maybe you should check the LWN's paper dealing with the architecture of JFFS2, that
mainly explain the 5 sector limit. IMHO, I've understood that it is always safe to
turn JFFS2_RESERVED_BLOCKS_WRITE to whatever small you like, but in
that case you would not be able to get "more free" space when all bytes are dirtied, unless
unlinking much more data that you would have done with ext2 or the likes (since copy
from sectors to sectors are the only way to get dirty bytes into free bytes).

IMHO, it should also be possible to change the code (cutting compression, truncate, ...)
in order to make a somewhat understandable RESERVED == 2, and continue without
hurting application code. For RESERVED<2, I'm not aware it could even be able to get
 it with the current architecture.

Note that JFFS2 is a very generic layer (you've got posix API, metadata journaling, on
the fly compressing, binary compatiblity with linux storage ...), all the great stuff that
makes it big-footed for just the updating of a single flash sector.

For instance, RedBoot has code to update its config parameters in a single sector.
This a small, specific need, that not sits upon JFFS2.


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss