Re: [PATCH] [RFC] UBI: Implement Fastmap support

[Shmulik Ladkani <shmulik.ladkani@gmail.com>]

Hi,

On Thu, 24 May 2012 12:03:28 +0200 Richard Weinberger <richard@nod.at> wrote:
> On 24.05.2012 11:56, Shmulik Ladkani wrote:
> > Hi Artem,
> >
> > On Thu, 24 May 2012 11:17:52 +0300 Artem Bityutskiy<dedekind1@gmail.com>  wrote:
> >> On Tue, 2012-05-22 at 18:55 +0200, Richard Weinberger wrote:
> >>>>> +    e = find_early_wl_entry(&ubi->free, max_pnum);
> >>>>
> >>>> This picks the eb with the lowest pnum within 'ubi->free'.
> >>>>
> >>>> When called with INT_MAX (for the FM_DATA), why do you need to pick
> >>> a
> >>>> free eb with the minimal pnum? The FM_DATA EBs may reside everywhere
> >>> (as
> >>>> the FM_SB holds their location).
> >>>> So why not pick the eb with a medium EC value (as done for standard
> >>>> get_peb calls)? That might be better wear-leveling wise.
> >>>
> >>> Fair point.
> >>> I'll fix that.
> >>> Artem, any comments on that?
> >>
> >> The 'find_early_wl_entry()' function is used (currently) only at early
> >> stages. At these stages the we do not have the PEBs sorted by EC. We
> >> have just a list. This function should not be use after the WL subsystem
> >> is initialized.
> >
> > 'find_early_wl_entry' is only called from 'ubi_wl_get_fm_peb'.
> 
> Correct.
> 
> > 'ubi_wl_get_fm_peb' is called twice from within 'ubi_update_fastmap':
> > First call, to get the FM_SB, with 'max_pnum' set as UBI_FM_MAX_START.
> > Second, to get FM_DATA pebs, with 'max_pnum' as -1, do indicate "no
> > matter the location, give me pebs from the free pool".
> 
> Correct. Maybe I should rename find_early_wl_entry() to 
> find_wl_entry_for_fastmap() or something like that...

Yes, name is misleading.
How about the ugly but descriptive: find_wl_entry_by_max_pnum?

Regards,
Shmulik