public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: "Shawn J. Goff" <shawn7400@gmail.com>,
	Kevin Cernekee <cernekee@gmail.com>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org, agust@denx.de
Subject: Re: [RFC/PATCH] mtd: m25p80: set writebufsize
Date: Fri, 03 Feb 2012 08:14:56 +0200	[thread overview]
Message-ID: <1328249696.6750.41.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20120201111153.3c1fe085@pixies.home.jungo.com>

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

On Wed, 2012-02-01 at 11:11 +0200, Shmulik Ladkani wrote:
> On Tue, 31 Jan 2012 09:46:40 -0800 Brian Norris <computersforpeace@gmail.com> wrote:
> > I'm wondering now: how do we guarantee that we're picking the
> > *correct* writebufsize and not just one that *works*? It's only used
> > by UBI, I think, so it depends on UBI's needs.
> > 
> 
> According to mtd.h, 'writebufsize' should be set to the "Size of the
> write buffer used by the MTD".
> 
> m25p->page_size should be set to the size of the device's data buffer
> (used by the Page Program operation).
> 
> Hence for m25p80, 'flash->mtd.writebufsize = flash->page_size' seems
> right.
> 
> BTW 'writebufsize' is propagated to UBI's 'max_write_size' which
> currently affects UBIFS write-buffer size.
> 
> It should be set to "the maximum amount of bytes the underlying flash is
> able to program at a time" (according to ubifs/io.c).
> 
> Hence again, for m25p80, 'flash->page_size' seems adequate.

This parameter was introduced for NOR flashes, and in NAND flashes
context it looks weird. Probably we could document this better. But
basically, it describes how much data the driver is able to write at a
time. All NAND drivers write only one page at a time, so this parameter
should be set to NAND page size.

Imagine if you created a striping layer on top of 2 MTD devices to
speed-up the I/O. In this case you would most probably make
'writebufsize' = 2xNAND pages. UBIFS would then try to do I/O in
'writebufsize' units for optimal performance, unless there is a sync
command for example, in which case UBIFS would write the last chunk of
date in smaller 'min_io_size' (=NAND page size) unit to waste less
space.

UBIFS also needs to know max_write_size for recovery to calculate how
fare a corruption caused by an unclean reboot can span (on the above
example, a normal corruption can only affect 2 NAND pages).

To summarize:

mtd->writesize = UBIFS->min_io_size - normal min. I/O unit
mtd->writebufsize = UBIFS->max_write_size - how much data the driver may
write at a time, defines the max. corruption size, gives fastest I/O.

And there is also mtd->subpage_shft -> sub-page size :-) This exists on
some NANDs. UBI uses it to pack its headers more tightly and waste less
space. We do not make this to be our min_io_size because we assume the
I/O speed in subpage-sized units is slow. Indeed, in case of normal
NANDs the whole page is written anyway, just padded with 0xFFs.

Anyway, pushed to l2-mtd.git, thanks! Added
Cc: stable@kernel.org [2.6.38+] as well.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-02-03  6:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31  8:06 [RFC/PATCH] mtd: m25p80: set writebufsize Brian Norris
2012-01-31 14:08 ` Shawn J. Goff
2012-01-31 17:46   ` Brian Norris
2012-02-01  9:11     ` Shmulik Ladkani
2012-02-03  6:14       ` Artem Bityutskiy [this message]
2012-02-03  7:52         ` Shmulik Ladkani

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=1328249696.6750.41.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=agust@denx.de \
    --cc=cernekee@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=shawn7400@gmail.com \
    --cc=shmulik.ladkani@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