Re: JFFS2_RESERVED_BLOCKS_*

[David Woodhouse <dwmw2@infradead.org>]

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