All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Dirk Behme <dirk.behme@gmail.com>
Cc: dirk.behme@de.bosch.com, linux-mtd@lists.infradead.org,
	Achim Dahlhoff <Achim.Dahlhoff@de.bosch.com>
Subject: Re: [PATCH] UBIFS: add tolerance to use variable writesize
Date: Mon, 01 Jul 2013 10:55:09 +0300	[thread overview]
Message-ID: <1372665309.22014.40.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1368634865-4186-1-git-send-email-dirk.behme@gmail.com>

On Wed, 2013-05-15 at 18:21 +0200, Dirk Behme wrote:
> From: Achim Dahlhoff <Achim.Dahlhoff@de.bosch.com>
> 
> UBIfs adapts it‘s structures according to the minimum writeSize reported
> by the MTD device. For NOR flash devices, this is normally 1. For NOR
> devices with internal hardware-ECC it might be more, such as the S-Die
> flash chips of Micron which can use an internal ECC if the chip is
> accessed in 32 byte chunks.
> 
> The UBIfs mount process checks and compares the writeSize set in the
> image and the writeSize reported from the /dev/mtd . UBIfs will fail
> to mount if the values differ. It should, though, not be a problem to
> mount an image which was created with a writeSize larger than that of
> the MTD, if it is larger by an integer factor.
> 
> This commit changes the check in a way so it will allow the image
> writeSize to be larger than that of the MTD by an integer factor.
> It will allow to create images and deploy them on different devices
> using different writeSizes. writeSize found using values of 1, 8 and 32.
> 
> Signed-off-by: Achim Dahlhoff <Achim.Dahlhoff@de.bosch.com>

Hi Dirk,

first of all, sorry for long delay.

In UBIFS we have 2 flash parameters which are relevant to this
discussion:

1. min_io_size - minimum size of the I/O buffer, comes from
mtd->writesize
2. max_write_size - optimzl size of the I/O buffer, comes from
mtd->writebufsize

Take a look at io.c.

So it looks like what you actually want to do is to make sure you have
the right max_write_size, in which case UBIFS will do most of its writes
in max_wirte_size units. E.g., make it to be 32.

This can be done by teaching your flash driver to export correct
'mtd->writebufsize'. My guess is that you do not do this, and it
defaults to 'mtd->writesize'.

-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2013-07-01  7:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 16:21 [PATCH] UBIFS: add tolerance to use variable writesize Dirk Behme
2013-07-01  7:55 ` Artem Bityutskiy [this message]
2013-07-01  8:32   ` Dahlhoff Achim (CM-AI/PJ-CF32)
2013-07-01  9:33     ` Artem Bityutskiy
2013-07-04 11:50       ` Dirk Behme
     [not found] <1369237284-3559-1-git-send-email-dirk.behme@gmail.com>
2013-05-22 15:43 ` Dirk Behme

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=1372665309.22014.40.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=Achim.Dahlhoff@de.bosch.com \
    --cc=dirk.behme@de.bosch.com \
    --cc=dirk.behme@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.