All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Murali N <nalajala.murali@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Doubt regarding mtd test ( mtd_oobtest ) interpretation of oob data !
Date: Wed, 16 Sep 2009 13:50:23 +0300	[thread overview]
Message-ID: <1253098223.3778.16.camel@localhost> (raw)
In-Reply-To: <630851df0909160320y1721f8d8m23b0675d57558c28@mail.gmail.com>

On Wed, 2009-09-16 at 15:50 +0530, Murali N wrote:
> Hi Artem, can you please explain me a bit more about OOB_PLACE mode?.
> Also in mtd tests i have seen there is ooboffs field being used in
> OOB_AUTO mode.My doubt here was why AUTO mode cares about ooboffs
> field.ECC layout structure is defined clearly in the AUTO mode? am i
> correct? then what is the significance of ooboffs field?
> 
> i am not caring the ooboffs when the AUTO mode is selected in my
> driver? i was bit confused where it is mentioned in the MTD
> specification? can you please point to me if you have any info!!!

I do not remember all the glory details, but in short, OOB_PLACE is
used when you want to put your date to a specific _physical_ offset
withing the OOB. Very simple and straightforward. But I consider this
as legacy and I think no one should ever use this, and this should
be forbidden. I might be wrong, though.

OOB_AUTO is the sanest thing. Your OOB area may contain N small unused
regions of different length. E.g., see OneNAND's onenand_oob_64.
Different flashes have different layout. And OOB_AUTO is about
abstracting this, so all these small regions look like a contiguous
buffer to the applications. Size of this buffer is
mtd->ecclayout->oobavail bytes. You may write data do different offsets
of this buffer, and they will be automatically placed to corresponding
_physical_ offsets within the OOB. So applications do not care about
the OOB fragmentation, and always work with this _logical_ OOB_AUTO
buffer.

In OOB_AUTO case you cannot access the ECC bytes, because they are
hidden from you.

In OOB_PLACE you can, and I think it is a bad idea because it is not
applications' business to deal with ECCs. This should be hidden.

That's all I remember at this point. Nowadays we do not use OOB much.
E.g., UBI/UBIFS does not use it. Using OOB is bad, because modern
flashes may utilize _whole_ OOB for ECCs.

HTH.

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

      reply	other threads:[~2009-09-16 10:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-16  7:09 Doubt regarding mtd test ( mtd_oobtest ) interpretation of oob data ! Murali N
2009-09-16  7:23 ` Artem Bityutskiy
2009-09-16  9:36 ` Artem Bityutskiy
2009-09-16 10:20   ` Murali N
2009-09-16 10:50     ` 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=1253098223.3778.16.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nalajala.murali@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 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.