[RFC] [PATCH] UBI: refine wear leveling logic

[Alexander Schmidt]

Hi Artem,

On Thursday 29 March 2007, Artem Bityutskiy wrote:
> May I ask you for more explanation why you think your code is correct?

While writing this i assumed that erase and WL procedures are performed
sequentially (either by the background thread or, if the bgt is disabled,
by the produce_free_peb() function). Thank to your comment below I now
realised that erase/wl procedures could happen concurrently if the free
tree is empty and there are pending works (this is the only way that
could lead to your error scenario, right?).

If so then i propose to make get_peb() wait until the bgt produces a free
peb and not mix synchronous/asynchronous operations, as this would make
the code easier, IMO.

Regards,
Alex
> 
> > +
> > +	if (in_wl_tree(e, &ubi->used))
> > +		used_tree_del(ubi, e);
> > +	else if (unlikely(in_wl_tree(e, &ubi->scrub)))
> > +		scrub_tree_del(ubi, e);
> > +	else if (!in_wl_tree(e, &ubi->free))
> > +		prot_tree_del(ubi, e->pnum);
> >  	spin_unlock(&ubi->wl_lock);
> >  
> >  	err = schedule_erase(ubi, e, torture);
> 
> Fine, you schedule this eraseblock for erasure. At the same time the the
> WL worker moves data in there. The copy_leb() function will notice that
> the LEB is unmapped, and won't do copy. Then the WL worker will insert
> the eraseblock to a tree. At the same time the erase worker will insert
> the same wl_entry to the free tree. One of the trees will be screwed-up.
> 
> -- 
> Best regards,
> Artem Bityutskiy (Битюцкий Артём)
> 
>