public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Matthew L. Creech" <mlcreech@gmail.com>
Cc: bengardiner@nanometrics.ca, linux-mtd@lists.infradead.org
Subject: Re: Programming ubinized images
Date: Tue, 03 May 2011 14:37:44 +0300	[thread overview]
Message-ID: <1304422664.2737.102.camel@localhost> (raw)
In-Reply-To: <BANLkTimaW4hu6QrPEyMcCVWDzHd+5hVo+A@mail.gmail.com>

On Tue, 2011-05-03 at 02:43 -0400, Matthew L. Creech wrote:
> On Tue, Apr 26, 2011 at 4:00 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> >
> > We could teach the UBIFS tools and the kernel to deal with these things.
> > It is possible to do with a special flag in the UBIFS superblock which
> > would say - this FS has been just flashed, do not use space in
> > half-filled eraseblocks! Then probably we could go through these
> > half-filled eraseblocks and fix them up, and then remove that flag.
> >
> 
> Hi Artem, could you take a look at this patch when you get a chance?
> 
> My method for finding & cleaning the in-use LEBs is hacky: I just loop
> through all the LEBs in the FS, look up each one in the LPT, and
> "recover" anything not flagged as empty.  I *think* that should result
> in LEBs that have trailing empty space (SCANNED_EMPTY_SPACE) being
> re-mapped to a new PEB (via fix_unclean_leb()), which would clean up
> the empty pages.  So far I haven't gotten that condition to trigger
> with a real UBIFS image, so I'm not sure if it works correctly yet.
> 
> I may be way off on the wrong track though, so I just wanted to see if
> you think this seems like a reasonable way of doing it.  Thanks!

Hi, very very quick comment. First of all, it should be a flag in the
superblock. Can you make a separate patch which just introduces this
flag there?

But yes, something like you've done: once LPT is initialized, you should
look at the flag and if it is set, indeed do something like you have
done - walk all lebs, get lprops decription, and then you see if there
is any free space. If there is not - do not touch it. If there is free
space, then fixup it.

The recovery function will work, but it dos much more than needed, and
it prints various messages which we do not want. Make a separate
function for fix-up in sb.c. It is easy - you simply read c->leb_size -
lp->free, and then you use ubi_leb_change() and change the contents of
the LEB in-place atomically.

And after the fix-up you need to clean the flag in the SB.

Just make a nice series of patches :-)


-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

      reply	other threads:[~2011-05-03 11:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 18:37 Programming ubinized images Matthew L. Creech
2011-04-26  7:37 ` Ricard Wanderlof
2011-04-26  8:00 ` Artem Bityutskiy
2011-04-26  8:48   ` Matthew L. Creech
2011-04-26  8:49     ` Artem Bityutskiy
2011-05-03  6:43   ` Matthew L. Creech
2011-05-03 11:37     ` Artem Bityutskiy [this message]

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=1304422664.2737.102.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=bengardiner@nanometrics.ca \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mlcreech@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