lkml.org 
[lkml]   [2007]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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
\
 
 \ /
  Last update: 2007-03-26 00:19    [W:2.065 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site