Re: [PATCH] [RFC] UBI: Implement Fastmap support
From: Shmulik Ladkani
Date: Wed May 23 2012 - 02:19:28 EST
Hi Richard,
On Tue, 22 May 2012 20:57:25 +0200 Richard Weinberger <richard@xxxxxx> wrote:
> > Care to elaborate how come 'ubi->lookuptbl[pnum]' is NULL? What's the
> > exact flow leading to it?
>
> PEBs used by the fastmap sub-system are not known by the WL and EBA
> sub-system.
> A PEB used by fastmap contains mostly raw data. (It does not have any
> LEBs).
> E.g. If PEBs 0,1 and 2 are used by fastmap they are not in
> ubi->lookuptbl.
> So, right after attaching from a fastmap ubi->lookuptbl[0|1|2] is NULL.
> By writing a new fastmap 0, 1 and 2 will be put back to the WL
> sub-system and they appear in
> ubi->lookuptbl.
Thanks. Understood.
> > 'ubi_wl_get_fm_peb' doesn't clear the 'ubi_wl_entry' from the lookuptbl.
> > It does not free the 'ubi_wl_entry' either (seems like it should, no?)
>
> It removes a PEB from the free rb-tree.
> ubi->lookuptbl[pnum] does not matter at this time.
For practical matters, you are correct.
Design wise, it is bit inconsistent and confusing.
On one hand, you claim above that 'ubi->lookuptbl' holds the WL entries
known to WL subsystem - that is, lookuptbl is a data structure used and
maintained by the WL subsystem.
OTOH, when a PEB is removed from hands of WL (by a ubi_wl_get_fm_peb
call), you keep its WL entry assigned in ubi->lookuptbl.
I'll rethink this, see if there's a potential trouble here.
> > However 'ubi_wl_put_fm_peb' creates a 'ubi_wl_entry' if not found in
> > the lookuptbl.
>
> Yeah, but only in one corner case.
> See my comment:
> /* This can happen if we recovered from a fastmap the very
> * frist time and writing now a new one. In this case the wl
> system
> * has never seen any PEB used by the original fastmap.
> */
>
> > Formerly, wl_init was responsible for correctly populating
> > 'ubi->lookuptbl'. Can we somehow preserve this for FM pebs as well?
> >
>
> Currently fastmap "fixes" ubi->lookuptbl on demand. Is this a problem?
I guess not.
The only problem, as previously noted, is the failure to create a new
'ubi_wl_entry' when the PEB needs to be returned to WL subsystem.
If all relevant wl entries are created during 'wl_init' (including those
currently associated to the fastmap), then we are fine, as internal
failures within 'wl_init' propagate back to the attach code.
I'll give it some more thought.
Regards,
Shmulik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/