public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Nancy <nancydreaming@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: Is there possible to integrate mtd ubi ubifs latest version in one git tree?
Date: Tue, 15 Apr 2008 18:41:17 +0300	[thread overview]
Message-ID: <1208274077.5965.246.camel@sauron> (raw)
In-Reply-To: <20080415152104.GA8513@shareable.org>

n Tue, 2008-04-15 at 16:21 +0100, Jamie Lokier wrote:
> It would be good if the erase-counters (and indeed metadata needed for
> fast mounting) were also records in the log/trees held in other
> blocks, but I guess you'd need to closely couple with the filesystems
> logging.  And that would be a layer violation, tricky and ugly in the
> UBI API.

Yeah, that would be nice. Well, if one really wants it is possible to
teach UBI to save erase-counter somewhere else before erasing. Should
not be difficult. UBI has general mechanism of so-called "internal
volumes" which may be added and used for that purposes. But it does not
sound worth the trouble for me :-)

But fast mounting is a separate area which would need full re-design and
many additional complications. As I said before, we are planning to at
lease create a short document about the possible UBI2 design.

The strength of current UBI is its relative simplicity, thus robustness.
It does not have any on-flash trees. UBIFS does - and the complexity is
an order of magnitude higher then UBI's complexity :-)

Imagine you would store some kind of logs and trees on the flash in UBI.
You would refer physical eraseblock from these trees by numbers, surely?
Think about difficulties introduced by randomly distributed bad
eraseblocks. With current UBI, one can prepare an image and send it to
factory, where it will be flashed to all devices. The same image,
irrespectively on how bad blocks are distributed. Simple. But in case
UBI2 (imaginable) which would have some trees, where a tree could refer,
say, an eraseblock 1006, things would have been much more difficult.
This eraseblock 1006 could be a bad block for example. This is only one
example.

But that stuff is doable I believe, although trickier that current UBI.
And we hope, once UBI/UBIFS gets stabilized and used, we or someone else
may do the tricks.

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

  reply	other threads:[~2008-04-15 15:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-11  6:48 Is there possible to integrate mtd ubi ubifs latest version in one git tree? Nancy
2008-04-12  9:57 ` Artem Bityutskiy
2008-04-12  9:59   ` Artem Bityutskiy
2008-04-12 10:10   ` Artem Bityutskiy
2008-04-14  4:46     ` Nancy
2008-04-14  9:05       ` Artem Bityutskiy
2008-04-15 11:41         ` Jamie Lokier
2008-04-15 11:44           ` Artem Bityutskiy
2008-04-15 15:21             ` Jamie Lokier
2008-04-15 15:41               ` Artem Bityutskiy [this message]
     [not found]         ` <bae050c10804140435v5141dec6qd61b325a4a1ff6ad@mail.gmail.com>
     [not found]           ` <1208173090.5965.187.camel@sauron>
2008-04-15 12:04             ` Nancy
2008-04-16  6:11               ` 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=1208274077.5965.246.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=jamie@shareable.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nancydreaming@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