public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Felix Fietkau <nbd@openwrt.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBI: ignore/overwrite old data/PEBs after flashing
Date: Thu, 16 Oct 2014 14:27:49 +0300	[thread overview]
Message-ID: <1413458869.7906.199.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CACna6ry_vUS7ZnDG7k4=_q_vNkbn35mSm4V8u95KoienmrVPHw@mail.gmail.com>

On Thu, 2014-10-16 at 13:17 +0200, Rafał Miłecki wrote:
> On 16 October 2014 12:40, Artem Bityutskiy <dedekind1@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@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.

  reply	other threads:[~2014-10-16 11:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-16  5:34 UBI: ignore/overwrite old data/PEBs after flashing Rafał Miłecki
2014-10-16  9:10 ` Richard Weinberger
2014-10-16 10:21   ` Rafał Miłecki
2014-10-16 11:30     ` Artem Bityutskiy
2014-10-16 10:09 ` Artem Bityutskiy
2014-10-16 10:29   ` Rafał Miłecki
2014-10-16 10:40     ` Artem Bityutskiy
2014-10-16 11:17       ` Rafał Miłecki
2014-10-16 11:27         ` Artem Bityutskiy [this message]
2014-10-16 11:38           ` Rafał Miłecki
2014-10-16 11:54             ` Artem Bityutskiy
2014-10-16 13:51               ` Rafał Miłecki
2014-10-20 13:47                 ` Artem Bityutskiy
2014-10-20 18:40                   ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1413458869.7906.199.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nbd@openwrt.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox