Patchwork [1/8] mtd: block2mtd: initialize writebufsize

login
register
mail settings
Submitter Artem Bityutskiy
Date Feb. 3, 2012, 8:43 a.m.
Message ID <4fe90e9a0ba750bbdb34d04ca3437b493a19277f.1328257053.git.artem.bityutskiy@linux.intel.com>
Download mbox | patch
Permalink /patch/139315/
State New
Headers show

Comments

Artem Bityutskiy - Feb. 3, 2012, 8:43 a.m.
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
because this is actually the amount of data we write at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@kernel.org [2.6.38+]
Cc: Joern Engel <joern@lazybastard.org>
---
 drivers/mtd/devices/block2mtd.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Jörn Engel - Feb. 4, 2012, 6 p.m.
On Fri, 3 February 2012 10:43:07 +0200, Artem Bityutskiy wrote:
> 
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> 
> The writebufsize concept was introduce by commit
> "0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
> the maximum amount of data the device writes to the media at a time. This is
> an important parameter for UBIFS which is used during recovery and which
> basically defines how big a corruption caused by a power cut can be.
> 
> However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
> because this is actually the amount of data we write at a time.
> 
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Cc: stable@kernel.org [2.6.38+]
> Cc: Joern Engel <joern@lazybastard.org>

Acked-by: Joern Engel <joern@lazybastard.org>

From the description of 0e4ca7e it appears as if using a minimum of
say 8 for ubifs recovery would have done the trick as well.  Oh well!

Jörn
Artem Bityutskiy - Feb. 6, 2012, 9:07 a.m.
On Sat, 2012-02-04 at 13:00 -0500, Jörn Engel wrote:
> > Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> > Cc: stable@kernel.org [2.6.38+]
> > Cc: Joern Engel <joern@lazybastard.org>
> 
> Acked-by: Joern Engel <joern@lazybastard.org>

Added, thanks!

> From the description of 0e4ca7e it appears as if using a minimum of
> say 8 for ubifs recovery would have done the trick as well.  Oh well!

It actually need to know the maximum size of the corrupted area. In case
of block2mtd in theory, the whole 512 bytes may be corrupted, even
though I update 1 byte. For real CFI NORs - it is 16 bytes AFAIR.

Patch

diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index d9e75da..0fccf14 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -283,6 +283,7 @@  static struct block2mtd_dev *add_device(char *devname, int erase_size)
 	dev->mtd.size = dev->blkdev->bd_inode->i_size & PAGE_MASK;
 	dev->mtd.erasesize = erase_size;
 	dev->mtd.writesize = 1;
+	dev->mtd.writebufsize = PAGE_SIZE;
 	dev->mtd.type = MTD_RAM;
 	dev->mtd.flags = MTD_CAP_RAM;
 	dev->mtd._erase = block2mtd_erase;