Comments

Am 22.06.2012 18:05, schrieb Nikita V. Youshchenko:
> As far as I understand, this happens because all PEBs at the beginning of > device are occupied. But this will always be the case after creating image > with ubinize...
ubinize will also get fastmap support.
But first we have to finish the kernel level support.
> How to overcome this?
Can you please try the attached patch?
This patch allows the WL-worker to produce free anchor PEBS.
Thanks,
//richard
P.s: Please use the most current fastmap code!

> > How to overcome this?>> Can you please try the attached patch?> This patch allows the WL-worker to produce free anchor PEBS.
This patch does not apply against 'fastmap' branch of
git://git.infradead.org/linux-ubi.git
And incompatibility is big enough to be not obviously resolvable.
> P.s: Please use the most current fastmap code!
Where to get that?
Nikita

Hi!
Am 22.06.2012 19:26, schrieb Nikita V. Youshchenko:
> Where to get that?
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v12
In the meanwhile I had the chance to look closer at the issue.
The previously posted patch my help, but cannot help in all cases.
It can happen that a freshly created anchor (aka early) PEB will immediately
go into a fastmap pool, such that it cannot be used as fastmap super block.
I'll present a solution next week.
v12 has another issue.
If your flash contains bad PEBs the following WARN_ON() in fastmap.c will
spuriously trigger:
/*
* If fastmap is leaking PEBs (must not happen), raise a
* fat warning and fall back to scanning mode.
* We do this here because in ubi_wl_init() it's too late
* and we cannot fall back to scanning.
*/
if (WARN_ON(self_check_fastmap(ai) != ubi->peb_count -
ubi->bad_peb_count - used_blocks)) {
ret = UBI_BAD_FASTMAP;
kfree(fm);
goto free_hdr;
}
Instead of ubi->bad_peb_count it has to be ai->bad_peb_count.
Thanks,
//richard

Am 22.06.2012 20:46, schrieb Nikita V. Youshchenko:
> Tried code from there, plus patch you've sent, and still getting> > # ubidetach /dev/ubi_ctrl -m 2> UBI error: ubi_update_fastmap: could not find an anchor PEB> UBI warning: ubi_update_fastmap: Unable to write new fastmap, err=-28> UBI: mtd2 is detached from ubi0
As I said, the posted patch may or may not help.
Most likely the freshly created anchor PEBs got consumed by one
of the pools.
Anyway, I'll present a proper solution within the next few days.
Thanks,
//richard

On Fri, 2012-06-22 at 21:26 +0400, Nikita V. Youshchenko wrote:
> > > How to overcome this?> >> > Can you please try the attached patch?> > This patch allows the WL-worker to produce free anchor PEBS.> > This patch does not apply against 'fastmap' branch of > git://git.infradead.org/linux-ubi.git> > And incompatibility is big enough to be not obviously resolvable.
I've just pushed out the latest work of Richard to the "fastmap" branch,
should be up-to-date now. Thanks for feed-back, testing is very
appreciated and certainly should help merging this faster.

Am 27.06.2012 12:56, schrieb Artem Bityutskiy:
> I've just pushed out the latest work of Richard to the "fastmap" branch,> should be up-to-date now. Thanks for feed-back, testing is very> appreciated and certainly should help merging this faster.>
I'll send another patch set today.
It contains only minor coding style fixes and such stuff.
Before fastmap gets merged I'd like to have a discussion about fastmaps
parameters.
/* A fastmap anchor block can be located between PEB 0 and
* UBI_FM_MAX_START */
#define UBI_FM_MAX_START 64
/* A fastmap can use up to UBI_FM_MAX_BLOCKS PEBs */
#define UBI_FM_MAX_BLOCKS 32
/* 5% of the total number of PEBs have to be scanned while attaching
* from a fastmap.
* But the size of this pool is limited to be between UBI_FM_MIN_POOL_SIZE and
* UBI_FM_MAX_POOL_SIZE */
#define UBI_FM_MIN_POOL_SIZE 8
#define UBI_FM_MAX_POOL_SIZE 256
#define UBI_FM_WL_POOL_SIZE 25
Are we all fine with them?
Especially the size of both pools used by fastmap needs to be discussed more.
If the pool size is too small UBI was to write the fastmap very often.
A too large pool means that attaching takes longer because fastmap has to rescan
more PEBs.
Thanks,
//richard

> Especially the size of both pools used by fastmap needs to be discussed> more. If the pool size is too small UBI was to write the fastmap very> often. A too large pool means that attaching takes longer because> fastmap has to rescan more PEBs.
I'd prefer to see those configurable.
I see two obvious cases when different settings are needed.
First is system that has very little changes at runtime. Maybe as small as
save user settings if he ever changes those. Everything else is readonly.
Then, better to have lower pool size to make attach faster.
Second is system with extensice writes expected. Then indeed pool needs to
be larger to avoid too often fastmap writes.
Nikita

On Wed, 2012-06-27 at 15:07 +0400, Nikita V. Youshchenko wrote:
> > Especially the size of both pools used by fastmap needs to be discussed> > more. If the pool size is too small UBI was to write the fastmap very> > often. A too large pool means that attaching takes longer because> > fastmap has to rescan more PEBs.> > I'd prefer to see those configurable.
I agree, all parameters should be in the fastmap anchor instead of being
hard-coded. It is OK to hard-code the default values for the
auto-format, but if the UBI image is created with ubinize - the user
should be able to tune for himself.