JFFS2_RESERVED_BLOCKS_*

JFFS2_RESERVED_BLOCKS_*

[Larry Doolittle]

I'm still fumbling around with MTD/JFFS2, but it does
seem to work.  I have a file system mounted that is
persistent across reboots, which is of course the goal.

Out of 4M Flash on this board, I set aside 1 M for JFFS2.
The rest is supposed to be used for the kernel and initrd,
and I guess I can now program that directly from Linux
instead of from the boot loader.

I have just a few kBytes of junk in that test filesystem, 
as confirmed by du:

/ # du /mnt/test
1       /mnt/test/ssh
0       /mnt/test/html
3       /mnt/test/init.d
11      /mnt/test
/ # 

Imagine my surprise when I read the df output:

/ # df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ram0                 3835      2359      1476  62% /
/dev/mtdblock2            1024       328       696  32% /mnt/test

Tracing through the source, I discover this is because there
are JFFS2_RESERVED_BLOCKS_WRITE == 5 blocks reserved.  The
Intel 28F320B3 I have has 64 kB erase blocks, so this
reservation accounts for 320 kB.

Maybe my use is atypical, and maybe 5 blocks is a theoretical
minimum.  I don't want to sound like a complainer, either --
this file system certainly looks like it meets my needs.
I guess I just want to point out the superficial imbalance
between the amount of sweat people pour out on projects like
busybox to reduce code size by a few kB, when there is 320 kB
"just lying around" on any JFFS2 on a 64 kB erase block chip.

Maybe the 5-block reservation could be pointed out in the
documentation, and some explanation given as to why this
is reasonable.  Other people may have less wiggle-room in
their design, and we wouldn't want them to be surprised
and get angry with embedded Linux.

      - Larry

Re: JFFS2_RESERVED_BLOCKS_*

[David Woodhouse]

ldoolitt@recycle.lbl.gov said:
>  Maybe my use is atypical, and maybe 5 blocks is a theoretical
> minimum.  I don't want to sound like a complainer, either -- this file
> system certainly looks like it meets my needs. I guess I just want to
> point out the superficial imbalance between the amount of sweat people
> pour out on projects like busybox to reduce code size by a few kB,
> when there is 320 kB "just lying around" on any JFFS2 on a 64 kB erase
> block chip.

Theoretical minimum is one block, not five. Give me formal proof that 
this is also the _practical_ minimum, and we can drop the 
overly-conservative limits.

Actually, we'd drop it to two, to allow for at least one block going bad on 
us. More than two on NAND flash.

--
dwmw2

Re: JFFS2_RESERVED_BLOCKS_*

[dennis noermann]

I am using

#define JFFS2_RESERVED_BLOCKS_BASE 0
#define JFFS2_RESERVED_BLOCKS_WRITE (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_DELETION (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_GCTRIGGER (JFFS2_RESERVED_BLOCKS_BASE + 2)
#define JFFS2_RESERVED_BLOCKS_GCBAD (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_GCMERGE (JFFS2_RESERVED_BLOCKS_BASE)

for an 640kb partition on 2*intelF320 (8MB)
so 128 kb are wastet , it is working fine , till i am copying more than
the 512kb free space in the partition , then deleting doesnt work

i think there is only 1 littel mistake in my config , but i was to lazy to
figger out the problem
JFFS2_RESERVED_BLOCKS_DELETION has to be set to 0 i think , i will try it
next time i have time :)

dennis

On Tue, 2 Oct 2001, David Woodhouse wrote:

>
> ldoolitt@recycle.lbl.gov said:
> >  Maybe my use is atypical, and maybe 5 blocks is a theoretical
> > minimum.  I don't want to sound like a complainer, either -- this file
> > system certainly looks like it meets my needs. I guess I just want to
> > point out the superficial imbalance between the amount of sweat people
> > pour out on projects like busybox to reduce code size by a few kB,
> > when there is 320 kB "just lying around" on any JFFS2 on a 64 kB erase
> > block chip.
>
> Theoretical minimum is one block, not five. Give me formal proof that
> this is also the _practical_ minimum, and we can drop the
> overly-conservative limits.
>
> Actually, we'd drop it to two, to allow for at least one block going bad on
> us. More than two on NAND flash.
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

Re: JFFS2_RESERVED_BLOCKS_*

[David Woodhouse]

dennis.noermann@noernet.de said:
> for an 640kb partition on 2*intelF320 (8MB) so 128 kb are wastet , it
> is working fine , till i am copying more than the 512kb free space in
> the partition , then deleting doesnt work

> i think there is only 1 littel mistake in my config , but i was to
> lazy to figger out the problem JFFS2_RESERVED_BLOCKS_DELETION has to
> be set to 0 i think , i will try it next time i have time :) 

That sounds like a reasonable assessment, and it's good news that it seems 
to work. However, I believe there are one or two corner cases in the garbage 
collection code, which should almost never actually get triggered, in which 
it's not quite sufficient. So I'm unhappy about reducing it in the general 
case until I can prove that it's safe. 

--
dwmw2

Re: JFFS2_RESERVED_BLOCKS_*

[Jörn Engel]

Hi!

> Theoretical minimum is one block, not five. Give me formal proof that 
> this is also the _practical_ minimum, and we can drop the 
> overly-conservative limits.

Formal proof is a tough one. But the difference between theoretical
and practical minimum should be a couple of bugs, that might be found
with a bigger userbase.
What wheel do I have to turn, to lower the limit myself?

Jörn

-- 
To solve an interesting problem, 
start by finding a problem that is interesting to you.

Re: JFFS2_RESERVED_BLOCKS_*

[dennis noermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 947 bytes --]


On Wed, 3 Oct 2001, [iso-8859-1] Jörn Engel wrote:

> Hi!
>
>
> Formal proof is a tough one. But the difference between theoretical
> and practical minimum should be a couple of bugs, that might be found
> with a bigger userbase.
> What wheel do I have to turn, to lower the limit myself?
>
> Jörn

nodelist.h

#define JFFS2_RESERVED_BLOCKS_BASE 3
#define JFFS2_RESERVED_BLOCKS_WRITE (JFFS2_RESERVED_BLOCKS_BASE + 2)
#define JFFS2_RESERVED_BLOCKS_DELETION (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_GCTRIGGER (JFFS2_RESERVED_BLOCKS_BASE + 3)
#define JFFS2_RESERVED_BLOCKS_GCBAD (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_GCMERGE (JFFS2_RESERVED_BLOCKS_BASE)


you see all depends on JFFS2_RESERVED_BLOCKS_BASE
try to  decrease this
i am running it with
JFFS2_RESERVED_BLOCKS_BASE 0
JFFS2_RESERVED_BLOCKS_GCTRIGGER (JFFS2_RESERVED_BLOCKS_BASE + 2)

and it works fine

dennis

Re: JFFS2_RESERVED_BLOCKS_*

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  Formal proof is a tough one. But the difference between theoretical
> and practical minimum should be a couple of bugs, that might be found
> with a bigger userbase.

True, but people are using this in production, so just changing the default
isn't particularly sane. 

Changing the default would also require that I (or someone) actually has
enough time available in the near future to _fix_ those bugs when they turn
up. I'm hoping that we can get a contract soon which involves reducing the
GC overhead, and I can spend some real time on it. Until then, I have to 
leave it at the overly-conservative current value.

I can point you at some of the offending bugs already. We decompress and 
recompress data on garbage-collection. If it's not changing, we should just 
copy the compressed version intact. If it _is_ changing because the block 
we're garbage-collecting is partially obsoleted by later writes, we should
make sure the new compressed version isn't larger than the old version 
unless we have slack space. If it would exceed the available space, we need 
to copy it intact and keep the old version number. 

We probably also need to make the decisions on whether to allow writes more 
fine-grained - actually working on the number of bytes available not the 
number of blocks.

> What wheel do I have to turn, to lower the limit myself? 

This one's been answered. If it breaks, you get to keep both pieces :)

--
dwmw2