[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choice of min_free_size




bjornw@xxxxxxx.com said:
> R = total amount of obsolete data 

We don't currently keep track of that, do we? fmc->dirty_size is the total
size on the flash of the nodes which are completely obsoleted - it doesn't
count nodes which have been partially obsoleted.

bjornw@xxxxxxx.com said:
>  As long as you start with an empty sector (remember that 15-game!)
> you can always rearrange the layout to put all the obsolete data (R)
> consecutively (that is, it was obsolete data, it's free space now).
> There's no risk of deadlocking there - the risks come from how you
> judge when to stop, how you judge when to start, and how you judge
> whether to defrag nodes or not.

I'm not convinced of that.

If, for example, you have sector_size 128KB, and you have three dirty 
blocks each of 50KB, you cannot fit those into a single sector - you have 
to fragment one of them, which means you're taking an extra 80 bytes for 
the extra jffs_raw_inode.

You may be able to get away with saying "as long as you start with an empty 
sector and 80 bytes more just in case".


bjornw@xxxxxxx.com said:
> As long as you start with an empty sector (remember that 15-game!) you
> can always rearrange the layout to put all the obsolete data (R)
> consecutively (that is, it was obsolete data, it's free space now).

I'm inclined to accept that without proof for the nodes which are 100%
obsoleted. It's not immediately obvious to me that it's the case when you 
include in R the nodes which are partially obsoleted. The potential for 
needing an unknown number of extra jffs_raw_inode headers concerns me.

bjornw@xxxxxxx.com said:
>  I think the only non-obvious part of this is the defrag part. What do
> you think ? 

I agree, but I'm a little suspicious. obvious != proven. 


--
dwmw2