Re: UBI/UBIFS: dealing with MLC's paired pages

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Fri, 30 Oct 2015 13:43:15 +0200
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> On Fri, 2015-10-30 at 10:45 +0100, Boris Brezillon wrote:
> > Moreover, the standard GC only takes place when you can't find a free
> > LEB anymore, which will probably happen when you reach something
> > close
> > to half the partition size in case of MLC chips (it may be a bit
> > higher if you managed to occupy more than half of each LEB capacity).
> > This means that your FS will become slower when you reach this limit,
> > though maybe this can be addressed by triggering the GC before we run
> > out of free LEBs.
> 
> Right. I'd call it a detail. But the big picture is - if you have to GC
> all the data you write, you write twice. When exactly you do the second
> write is a detail - sometimes it is deferred, it is in background etc,
> sometimes right away - you have to GC older data before being able to
> write new data.

You're right, but it makes a big difference when all your writes are
taking longer because you need to run the GC to retrieve a free LEB, and
this is probably what's gonna happen when your FS raises ~1/2 its
maximum size. Doing it in background (collecting a few valid nodes on
each GC step and letting user operations take place between each of
these step) should help mitigating this problem.

> 
> Now, by no means I am criticizing you or your decisions, you are doing
> great job. I am more like summarizing and trying to give you some food
> for thoughts. :-)

No problem, I don't take it personally. I actually think arguing
on technical stuff is a good way to find the best solution ;-).

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com