UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 13:17 +0200, Rafał Miłecki wrote:
> On 16 October 2014 12:40, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > On Thu, 2014-10-16 at 12:29 +0200, Rafał Miłecki wrote:
> >> On 16 October 2014 12:09, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> >> > Then the solution would be to pad your image with 0xFFs and write it.
> >> > UBI will notice PEBs which do not contain UBI headers and will erase
> >> > them in background.
> >>
> >> That would be trivial trick to implement, however it's far from being
> >> user friendly. Most devices have 128 MiB flash and our firmware
> >> (OpenWrt) is only ~4 MiB big. It would be a waste of
> >> space/bandwidth/time to provide firmware images padded with over 120
> >> MiB of 0xFF.
> >
> > Right, this is a work-around, and it is OK for a work-around to be
> > suboptimal, generally speaking.
> >
> > If you want a more optimal work-around, it will be more intrusive. One
> > idea would be to can create a small specialized kernel driver which will
> > start before UBI and clean-up your flash: erase PEBs you specify it.
> > Something like 'mtd/flashcleaner.ko'.
> 
> I'm not sure if something like this is possible. My driver would need
> to have a very good understanding of UBI to know which PEBs to leave
> and which to clean. I would need to find out which PEBs were recently
> flashed (are part of the just-installed firmware) and which are left
> from the previous installation.

Why? All you need is to erase all PEBs which contain those "100MiB of
rubbish". They will be sequential.

And of course this would be a one-time driver. You'd need to run it only
on the very first boot.

On the other hand, may be you can add an "wipe_rubbish" kind of UBI
module parameter, which would make it to just erase any PEB containing
"rubbish", i.e., anything without an EC header. My worry is that this
could be potentially dangerous - if you have a PEB corrupted, and it
contains precious data, UBI will just destroy the precious data instead
of refusing the flash. So a feature like this would need to be used
carefully.