diff mbox

[1/8] mtd: block2mtd: initialize writebufsize

Message ID 4fe90e9a0ba750bbdb34d04ca3437b493a19277f.1328257053.git.artem.bityutskiy@linux.intel.com
State Accepted
Commit b604387411ec6a072e95910099262616edd2bd2f
Headers show

Commit Message

Artem Bityutskiy Feb. 3, 2012, 8:43 a.m. UTC 
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(-)

Comments

Jörn Engel Feb. 4, 2012, 6 p.m. UTC | #1 
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. UTC | #2 
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.
diff mbox

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;