[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1345209115.27859.84.camel@sauron.fi.intel.com>
Date: Fri, 17 Aug 2012 16:11:55 +0300
From: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
To: Richard Weinberger <richard@....at>
Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
adrian.hunter@...el.com, Heinz.Egger@...utronix.de,
thomas.wucher@...utronix.de, shmulik.ladkani@...il.com,
tglx@...utronix.de, tim.bird@...sony.com, Marius.Mazarel@...l.ro,
nyoushchenko@...sta.com
Subject: Re: UBI fastmap updates
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
One thing which just came to my mind why looking at other MTD e-mails. I
do not know if it is relevant for fastmap or not, just want you to
check.
In UBIFS we have we have the "fixup" feature which is used to
work-around dumb flashers which are present in many factories:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup
This is because the "correct" UBI flasher should be able to skip empty
space when flashing, see here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
So with this fixup flag UBIFS will basically read all its eraseblocks
which have empty spece which it will use, and write them back. Just to
make the empty space writable again. This is done only once on the very
first boot.
We do not do anything like this in UBI because UBI does not need this,
it does not have any complex data structures on the media.
With fastmap - I am unsure. I think it is not a problem, because
probably you never append more data, you just re-write everything,
right?
--
Best Regards,
Artem Bityutskiy
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists