jffs2 sumtool bug ?

jffs2 sumtool bug ?

[Matthieu CASTET]

Hi,

In sumtool, in pad_block_if_less_than, we pad and write to a new 
eraseblock if "(data_ofs + req > erase_block_size - datasize)".
But datasize = req + the size of the summary node.

So we pad and write to a new eraseblock if there is not the space for 
the summary node and (the node we are wanting to write) * 2.

Why the condition isn't "(data_ofs > erase_block_size - datasize)" ?


thanks,

Matthieu


PS : about summary, could the sumtool change the order of the nodes to 
avoid to waste too much space. For example if the eraseblock is 16KB and 
we have 4 nodes of 4KB. Sumtool will put in the first eraseblock 3 
nodes, 4KB will be wasted for the sumary node. In this wasted 4KB, we 
could have put smaller nodes.

PS2 : How the kernel implementation does ? Does it try to minimize 
summary overhead, by managing to minimize the summary node size ?

Re: jffs2 sumtool bug ?

[David Woodhouse]

On Wed, 2007-05-23 at 10:10 +0200, Matthieu CASTET wrote:
> PS : about summary, could the sumtool change the order of the nodes to 
> avoid to waste too much space. For example if the eraseblock is 16KB and 
> we have 4 nodes of 4KB. Sumtool will put in the first eraseblock 3 
> nodes, 4KB will be wasted for the sumary node. In this wasted 4KB, we 
> could have put smaller nodes.

Theoretically, yes. But there's easier things to do first. We could
halve the size of the summary node itself, for example.

-- 
dwmw2