Messages in this thread | | | Date | Sun, 25 Mar 2007 13:49:58 -0800 (PST) | From | David Lang <> | Subject | Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images |
| |
On Sun, 25 Mar 2007, Jörn Engel wrote:
> On Wed, 21 March 2007 12:25:34 +0100, Thomas Gleixner wrote: >> On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote: >>> >>> Also LogFS currently requires erasesizes of 2^n. >> >> Last time I talked to you about that, you said it would be possible and >> fixable. > > Actually, no. LogFS is not broken, there is nothing to fix. > > And there is no fundamental reason why UBI should export blocks with > non-power-of-two sizes. UBI currently consists of two parts that are > intimately intertwined in the current implementation, but have > relatively little connection otherwise. > > 1. Logical volume management. > 2. Static volumes. > > Logical volume management can just as easily move its management > information into a table, instead of having it spread across all blocks. > Blocks can keep their original size. Since you have to scan flash > anyway, you can also scan for a table, compare a magical number and do > some extra check to protect yourself against a UBI image inside some > logical volume. No big deal.
if you are being paranoid about write cycles putting the write count in the block you are writing avoids doing an erase/write elsewhere
although, since you can flip bits to 1 without requireing an erase you could sacrafice some space and say that your table has a normal counter for the number of times the block has been erased, but a 'tally counter' where you turn one bit on each time you erase the block, and when you fill up the tally block you re-write the entire table, clearing all the tallys. if you have relativly large eraseblocks it seems like you could afford to sacrafice the space in your master table to avoid erases of it
IIRC someone said that the count per block was 128 bits? if so you could have a master table with a 32 bit integer (4B writes) + 96 bits of tally so that you would only have to re-write the table when a block on the flash has been erased 96 times. with this approach the wear on your table is unlikely to be a factor until the point where you are loosing a lot of other eraseblocks due to wear (at which point you could shift to a different block for your table, or retire the flash)
David Lang | |