All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Corentin Chary <corentin.chary@gmail.com>
Cc: Brijesh Singh <brij.singh@samsung.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Bosi Daniele <Daniele.Bosi@mta.it>,
	Adrian Hunter <adrian.hunter@nokia.com>
Subject: Re: UBI FS mounting time
Date: Wed, 22 Jul 2009 10:34:55 +0100	[thread overview]
Message-ID: <20090722093455.GD13613@shareable.org> (raw)
In-Reply-To: <71cd59b00907220057s6dbbdcb0vc23526836939aa97@mail.gmail.com>

Corentin Chary wrote:
> Do you think it would be better to fix the position of the anchor
> (first 2 good peb, ideally 0 and 1), or try to get a "good" position
> using ec and pnum ?
> 
> With a fixed position at the beginning, the scan process would be easier,
> because there is no need to reset if we find the anchor after normal blocks.
> But is does not sound very "wear leveling".

You can get wear levelling of anchor blocks by using indirect anchor
blocks, where a fixed 2 blocks points to a small set of "potential"
blocks to scan at mount time - a sort of tiny journal, small enough to
scan quickly.  The bulk of data needing for mounting is stored in
those journal blocks, and the true anchor blocks in pebs 0+1 point to
the range to be scanned.

Each mount/umount cycle, one of the scanned blocks will be updated,
except every so often the true anchor blocks in pebs 0+1 will be
updated to use a new range.

That's a two-level tree.  If you make a sufficiently deep multi-level
tree using the same idea - initial small set of indirect blocks (peb
0+1 in this example) pointing to small sets of of indirect blocks
... pointing to small sets of map blocks, then you can wear level the
whole flash evenly for any number of mount/umount cycles, and still
find the mount data quickly for any flash size.

(In fact you can run a whole filesystem like that, but that's another
topic).

For additional robustness against possible clustering of bad blocks,
make the initial small set be a sparse set of pebs over the flash
address space, instead of pebs 0+1.  I'd go for maximum address line
diversity.

-- Jamie

  parent reply	other threads:[~2009-07-22  9:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 17:00 UBI FS mounting time Bosi Daniele
2009-07-22  6:44 ` Adrian Hunter
2009-07-22  7:12   ` Corentin Chary
2009-07-22  7:38     ` Adrian Hunter
2009-07-22  7:57       ` Corentin Chary
2009-07-22  8:12         ` Adrian Hunter
2009-07-22  8:30           ` Artem Bityutskiy
2009-07-22  8:36             ` Artem Bityutskiy
2009-07-22  9:34         ` Jamie Lokier [this message]
2009-07-22  7:22   ` Canella Matteo
2009-07-22  8:10   ` Canella Matteo
2009-07-22  9:19     ` Adrian Hunter
2009-07-22 14:32       ` LEB size configuration (was: UBI FS mounting time) Canella Matteo
2009-07-22 14:53         ` LEB size configuration Artem Bityutskiy
2009-07-22 15:12           ` Canella Matteo
2009-07-22 15:15             ` Artem Bityutskiy
2009-07-22  9:30 ` UBI FS mounting time Artem Bityutskiy

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=20090722093455.GD13613@shareable.org \
    --to=jamie@shareable.org \
    --cc=Daniele.Bosi@mta.it \
    --cc=adrian.hunter@nokia.com \
    --cc=brij.singh@samsung.com \
    --cc=corentin.chary@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.