linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hujianyang <hujianyang@huawei.com>
To: Steve deRosier <derosier@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: Does UBIFS NAND ECC info get stored in OOB?
Date: Wed, 31 Dec 2014 10:15:24 +0800	[thread overview]
Message-ID: <54A35C3C.7070301@huawei.com> (raw)
In-Reply-To: <CALupW3Dv=OvY-5y_ScG1St8HUBYfXYpTnYAWDt_GJ+3+7KmC9Q@mail.gmail.com>

On 2014/12/31 3:44, Steve deRosier wrote:
> 
> So, does UBIFS utilize the OOB area to store ECC bits?  And if not,
> where/how does it store this information?

No, UBIFS doesn't use OOB area.

See func ubi_io_mark_bad() in drivers/mtd/ubi/io.c. If an eraseblock
turns to bad, UBI driver uses mtd interface to mark this eb as bad.

> 
> I'm starting to assume that you're simply saying that UBIFS itself
> doesn't use the OOB area, nor even handles the ECC itself, but that's
> up to the chip driver layer. And that the driver will handle the ECC
> and OOB as appropriate.  Am I correct?
>

Yes, you are right.

UBIFS doesn't directly write to OOB area. MTD or nand controller is
responsible to the data management in OOB area.

I think the announce "neither UBIFS nor UBI use OOB area" is compared
to the filesystem which directly write data to OOB area across the
interface provided by lower layer. For example, Yaffs2? I not sure
of it.

>
> And yes, I understand the 3.8 kernel is old, and we're upgrading, but
> I'm trying to figure out why we're having the problems as I'm assuming
> it's not a bug in the code but more of a configuration or process or
> hardware issue.
>

What kind of problems?

Thanks,
Hu

  parent reply	other threads:[~2014-12-31  2:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 19:44 Does UBIFS NAND ECC info get stored in OOB? Steve deRosier
2014-12-31  2:04 ` Josh Wu
2015-01-02 18:06   ` Steve deRosier
2015-01-04  3:52     ` Josh Wu
2015-01-09  5:05       ` Steve deRosier
2015-01-12  8:33         ` Josh Wu
2014-12-31  2:15 ` hujianyang [this message]
2015-01-02 18:12   ` Steve deRosier

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=54A35C3C.7070301@huawei.com \
    --to=hujianyang@huawei.com \
    --cc=dedekind1@gmail.com \
    --cc=derosier@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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;
as well as URLs for NNTP newsgroup(s).