Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "Ricard Wanderlof" <ricard.wanderlof@axis.com>,
	"HOUR Fréderic" <frederic.hour@safran-engineering.com>,
	"Kent Li" <Kent.Li@radisys.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Corrupt empty space
Date: Fri, 21 Mar 2014 10:13:56 +0200	[thread overview]
Message-ID: <1395389636.5163.104.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EAB4DF3@DBDE04.ent.ti.com>

On Fri, 2014-03-21 at 07:50 +0000, Gupta, Pekon wrote:
> Also, as there are multiple threads on same topic, If would be helpful
> if you can review and continue discussion over there.

Pekon, I apologise, I do not have time to review these threads now. If
this is difficult to implement generically on the MTD level, I trust
you.

I think there are only few places where UBI or UBIFS really need to know
an answer to the following question: is this min. I/O unit empty (never
written to) or not?

1. Recovery in UBIFS
2. Auto-formatting decision in UBI/UBIFS
3. Some debugging stuff in UBI where we try to make sure we write only
to empty pages.

If MTD layer provides helpers which UBIFS could call to get the answer,
that could probably work.

I mean, probably it is not necessary to make every read do this empty
page processing. It would be cool, but if the price is read throughput
drop, probably not worth it. All MTD reads can be the old style reads
which give no ECC protection when the page is empty. This could be
documented somewhere, BTW, in the code, and web site, too.

Then when UBI/UBIFS needs to know whether certain min. I/O unit is empty
or not, then UBI/UBIFS calls a special MTD helper function to get the
answer.

This would probably need some work in UBI/UBIFS, but I think this should
not be too difficult.

-- 
Best Regards,
Artem Bityutskiy

      reply	other threads:[~2014-03-21  8:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 17:35 Corrupt empty space HOUR Fréderic
2014-03-11  5:31 ` Kent Li
2014-03-11  7:00   ` Gupta, Pekon
2014-03-11  7:46   ` Artem Bityutskiy
2014-03-11  8:21     ` Brian Norris
2014-03-21  7:18     ` Gupta, Pekon
2014-03-21  7:31       ` Artem Bityutskiy
2014-03-21  7:43         ` Ricard Wanderlof
2014-03-21  7:53           ` Artem Bityutskiy
2014-03-21  7:50         ` Gupta, Pekon
2014-03-21  8:13           ` 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=1395389636.5163.104.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=Kent.Li@radisys.com \
    --cc=frederic.hour@safran-engineering.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    --cc=ricard.wanderlof@axis.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