* Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
@ 2007-11-21 14:27 Gregory CLEMENT
2007-11-21 16:08 ` Jörn Engel
0 siblings, 1 reply; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-21 14:27 UTC (permalink / raw)
To: linux-mtd; +Cc: Konstantin Baydarov
Hello,
I come back with my question because it seems that last time I sent
this mail mtd mailing list was done during few weeks, so maybe this
mail was lost.
2007/9/27, Gregory CLEMENT <gclement00@gmail.com>:
> Hi,
> this drivers seems pretty good and easily reviewable, so why it hadn't
> been included in mtd tree ?
>
> After some search I had not find any news on this patch, but maybe I
> missed something.
>
>
> 2006/12/2, Konstantin Baydarov <kbaidarov@dev.rtsoft.ru>:
> > On Wed, 22 Nov 2006 19:56:33 +0300
> > Konstantin Baydarov <kbaidarov@dev.rtsoft.ru> wrote:
> > >
> > > Corrected typo, renamed driver, got rid from redundant dependency.
> > > Also I've tested mtdblock_ro_bbfree as module - ok.
> >
> > Renamed driver to 'romblock'. Every entry of 'mtdblock' was replaced.
> > Debug level in DEBUG macros was replaced by corresponding macros.
> >
> > drivers/mtd/Kconfig | 7 ++
> > drivers/mtd/Makefile | 1
> > drivers/mtd/romblock.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 173 insertions(+)
> >
> > Index: mtd-2.6/drivers/mtd/romblock.c
> > ===================================================================
> > --- /dev/null
> > +++ mtd-2.6/drivers/mtd/romblock.c
> > @@ -0,0 +1,165 @@
> > +/*
> > + * Readonly Block Device Layer Over MTD
> > + *
> > + * (C) 2006 Baydarov Konstantin <kbaidarov@dev.rtsoft.ru>
> > + * Pantelis Antoniou <panto@intracom.gr>
> > + * David Woodhouse <dwmw2@infradead.org>
> > + *
> > + * It allows to use any filesystem on this device in
> > + * RO mode and thus gain faster mount times and better
> > + * throughput rates.
> > + *
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/slab.h>
> > +#include <linux/mtd/mtd.h>
> > +#include <linux/mtd/blktrans.h>
> > +
> > +struct romblock_map {
> > + struct mtd_blktrans_dev dev;
> > + /* block map for RO */
> > + int32_t *block_map;
> > + int32_t block_top;
> > + int32_t block_scantop;
> > +};
> > +
> > +static loff_t map_over_bad_blocks(struct mtd_blktrans_dev* dev, loff_t from)
> > +{
> > + int i, block;
> > + struct mtd_info *mtd = dev->mtd;
> > + struct romblock_map* dev_cont = container_of(dev, struct romblock_map, dev);
> > + int32_t *block_map = dev_cont->block_map;
> > + int32_t block_top = dev_cont->block_top;
> > + int32_t block_scantop = dev_cont->block_scantop;
> > +
> > + /* if no bad block checking is possible bail out */
> > + if (mtd->block_isbad == NULL)
> > + return from;
> > +
> > + /* first time in */
> > + if (block_map == NULL) {
> > + block_top = mtd->size / mtd->erasesize;
> > + block_map = kmalloc(sizeof(*block_map) * block_top, GFP_KERNEL);
> > + if (block_map == NULL) {
> > + printk (KERN_ERR "map_over_bad_blocks(): unable to allocate block map\n");
> > + return -ENOMEM;
> > + }
> > + for (i = 0; i < block_top; i++)
> > + block_map[i] = -1;
> > +
> > + for (i = 0; i < block_top; i++)
> > + if ((*mtd->block_isbad)(mtd, i * mtd->erasesize) == 0)
> > + break;
> > +
> > + if (i >= block_top) {
> > + printk (KERN_WARNING "map_over_bad_blocks(): all blocks bad!\n");
> > + return -EIO;
> > + }
> > + block_scantop = 0;
> > + block_map[0] = i;
> > +
> > + DEBUG(MTD_DEBUG_LEVEL0, "mtd: map %d -> %d\n", block_scantop, block_map[block_scantop]);
> > + }
> > +
> > + block = ((int)from / mtd->erasesize);
> > + if (block >= block_top)
> > + return (loff_t)-1;
> > +
> > + /* scan for bad block up to where we want */
> > + while (block >= block_scantop) {
> > + /* find a non bad block */
> > + for (i = block_map[block_scantop] + 1; i < block_top; i++)
> > + if ((*mtd->block_isbad)(mtd, i * mtd->erasesize) == 0)
> > + break;
> > +
> > + /* exhausted ? */
> > + if (i >= block_top) {
> > + printk (KERN_WARNING "map_over_bad_blocks(): no more good blocks!\n");
> > + return (loff_t)-1;
> > + }
> > +
> > + block_map[++block_scantop] = i;
> > + DEBUG(MTD_DEBUG_LEVEL0, "mtd: map %d -> %d\n", block_scantop, block_map[block_scantop]);
> > + }
> > +
> > + block = block_map[(int)from / mtd->erasesize];
> > + from = (block * mtd->erasesize) | ((int)from & (mtd->erasesize - 1));
> > + return from;
> > +}
> > +
> > +static int romblock_readsect(struct mtd_blktrans_dev *dev,
> > + unsigned long block, char *buf)
> > +{
> > + size_t retlen;
> > + unsigned long from;
> > +
> > + from = map_over_bad_blocks(dev, block<<9);
> > +
> > + if (dev->mtd->read(dev->mtd, from, 512, &retlen, buf))
> > + return 1;
> > + return 0;
> > +}
> > +
> > +static int romblock_writesect(struct mtd_blktrans_dev *dev,
> > + unsigned long block, char *buf)
> > +{
> > + size_t retlen;
> > +
> > + if (dev->mtd->write(dev->mtd, (block * 512), 512, &retlen, buf))
> > + return 1;
> > + return 0;
> > +}
> > +
> > +static void romblock_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
> > +{
> > + struct romblock_map *dev_cont = kmalloc(sizeof(*dev_cont), GFP_KERNEL);
> > +
> > + if (!dev_cont)
> > + return;
> > +
> > + memset(dev_cont, 0, sizeof(*dev_cont));
> > +
> > + dev_cont->dev.mtd = mtd;
> > + dev_cont->dev.devnum = mtd->index;
> > + dev_cont->dev.blksize = 512;
> > + dev_cont->dev.size = mtd->size >> 9;
> > + dev_cont->dev.tr = tr;
> > + dev_cont->dev.readonly = 1;
> > +
> > + add_mtd_blktrans_dev(&(dev_cont->dev));
> > +}
> > +
> > +static void romblock_remove_dev(struct mtd_blktrans_dev *dev)
> > +{
> > + del_mtd_blktrans_dev(dev);
> > + kfree(dev);
> > +}
> > +
> > +static struct mtd_blktrans_ops romblock_tr = {
> > + .name = "romblock",
> > + .major = 258,
> > + .part_bits = 0,
> > + .readsect = romblock_readsect,
> > + .writesect = romblock_writesect,
> > + .add_mtd = romblock_add_mtd,
> > + .remove_dev = romblock_remove_dev,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static int __init romblock_init(void)
> > +{
> > + return register_mtd_blktrans(&romblock_tr);
> > +}
> > +
> > +static void __exit romblock_exit(void)
> > +{
> > + deregister_mtd_blktrans(&romblock_tr);
> > +}
> > +
> > +module_init(romblock_init);
> > +module_exit(romblock_exit);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Baydarov Konstantin <kbaidarov@dev.rtsoft.ru>");
> > +MODULE_DESCRIPTION("Readonly Block Device Layer Over MTD");
> > Index: mtd-2.6/drivers/mtd/Makefile
> > ===================================================================
> > --- mtd-2.6.orig/drivers/mtd/Makefile
> > +++ mtd-2.6/drivers/mtd/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
> > obj-$(CONFIG_MTD_CHAR) += mtdchar.o
> > obj-$(CONFIG_MTD_BLOCK) += mtdblock.o mtd_blkdevs.o
> > obj-$(CONFIG_MTD_BLOCK_RO) += mtdblock_ro.o mtd_blkdevs.o
> > +obj-$(CONFIG_MTD_BLOCK_ROMBLOCK) += romblock.o mtd_blkdevs.o
> > obj-$(CONFIG_FTL) += ftl.o mtd_blkdevs.o
> > obj-$(CONFIG_NFTL) += nftl.o mtd_blkdevs.o
> > obj-$(CONFIG_INFTL) += inftl.o mtd_blkdevs.o
> > Index: mtd-2.6/drivers/mtd/Kconfig
> > ===================================================================
> > --- mtd-2.6.orig/drivers/mtd/Kconfig
> > +++ mtd-2.6/drivers/mtd/Kconfig
> > @@ -197,6 +197,13 @@ config MTD_BLOCK_RO
> > You do not need this option for use with the DiskOnChip devices. For
> > those, enable NFTL support (CONFIG_NFTL) instead.
> >
> > +config MTD_BLOCK_ROMBLOCK
> > + tristate "Readonly Block Device Layer Over MTD"
> > + depends on MTD_BLOCK!=y && MTD
> > + help
> > + Same as readonly block driver, but this allow you to mount read-only file
> > + systems from an MTD device, containing bad blocks.
> > +
> > config FTL
> > tristate "FTL (Flash Translation Layer) support"
> > depends on MTD && BLOCK
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
>
>
> --
> Gregory CLEMENT
> Adeneo
> 2, chemin du Ruisseau - BP21
> 69136 Ecully Cedex
> France
> Tel : +33-4 72 18 08 40
>
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 14:27 Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ? Gregory CLEMENT
@ 2007-11-21 16:08 ` Jörn Engel
2007-11-21 16:28 ` Gregory CLEMENT
0 siblings, 1 reply; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 16:08 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: linux-mtd, Konstantin Baydarov
On Wed, 21 November 2007 15:27:19 +0100, Gregory CLEMENT wrote:
>
> I come back with my question because it seems that last time I sent
> this mail mtd mailing list was done during few weeks, so maybe this
> mail was lost.
What problem does the driver solve? Why don't any of the existing
drivers solve it?
Jörn
--
/* Keep these two variables together */
int bar;
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 16:08 ` Jörn Engel
@ 2007-11-21 16:28 ` Gregory CLEMENT
2007-11-21 16:58 ` Josh Boyer
0 siblings, 1 reply; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-21 16:28 UTC (permalink / raw)
To: linux-mtd; +Cc: Jörn Engel
2007/11/21, Jörn Engel <joern@logfs.org>:
> On Wed, 21 November 2007 15:27:19 +0100, Gregory CLEMENT wrote:
> >
> > I come back with my question because it seems that last time I sent
> > this mail mtd mailing list was done during few weeks, so maybe this
> > mail was lost.
>
> What problem does the driver solve?
It allow to use cramfs/squashfs/fat in read-only on NAND flash for
embedded systems.
As far as I know, there is nothing to do it now in kernel: i.e. simply
managae badblock for read-only filesysteme.
PS: the patch don't apply on 2.6.23 kernel, I fixed it and I am
testing it before sending a updated patch.
> Why don't any of the existing
> drivers solve it?
>
> Jörn
>
> --
> /* Keep these two variables together */
> int bar;
>
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 16:28 ` Gregory CLEMENT
@ 2007-11-21 16:58 ` Josh Boyer
2007-11-21 17:07 ` Gregory CLEMENT
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Josh Boyer @ 2007-11-21 16:58 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: Jörn Engel, linux-mtd
On Wed, 21 Nov 2007 17:28:05 +0100
"Gregory CLEMENT" <gclement00@gmail.com> wrote:
> 2007/11/21, Jörn Engel <joern@logfs.org>:
> > On Wed, 21 November 2007 15:27:19 +0100, Gregory CLEMENT wrote:
> > >
> > > I come back with my question because it seems that last time I sent
> > > this mail mtd mailing list was done during few weeks, so maybe this
> > > mail was lost.
> >
> > What problem does the driver solve?
> It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> embedded systems.
Not really. It allows you to put one of those filesystems into
NAND using a bad-block aware program initially, and mount it. It
doesn't handle run-time bit flips or errors from what I can see.
josh
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 16:58 ` Josh Boyer
@ 2007-11-21 17:07 ` Gregory CLEMENT
2007-11-21 17:13 ` Josh Boyer
2007-11-21 17:15 ` Jörn Engel
2007-11-21 20:46 ` Ricard Wanderlof
2 siblings, 1 reply; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-21 17:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: Jörn Engel, linux-mtd
2007/11/21, Josh Boyer <jwboyer@linux.vnet.ibm.com>:
> On Wed, 21 Nov 2007 17:28:05 +0100
> "Gregory CLEMENT" <gclement00@gmail.com> wrote:
>
> > 2007/11/21, Jörn Engel <joern@logfs.org>:
> > > On Wed, 21 November 2007 15:27:19 +0100, Gregory CLEMENT wrote:
> > > >
> > > > I come back with my question because it seems that last time I sent
> > > > this mail mtd mailing list was done during few weeks, so maybe this
> > > > mail was lost.
> > >
> > > What problem does the driver solve?
> > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > embedded systems.
>
> Not really. It allows you to put one of those filesystems into
> NAND using a bad-block aware program initially, and mount it. It
> doesn't handle run-time bit flips or errors from what I can see.
>
> josh
>
Are these run-time bit flips can happen on reading only mode?
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:07 ` Gregory CLEMENT
@ 2007-11-21 17:13 ` Josh Boyer
0 siblings, 0 replies; 33+ messages in thread
From: Josh Boyer @ 2007-11-21 17:13 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: Jörn Engel, linux-mtd
On Wed, 21 Nov 2007 18:07:19 +0100
"Gregory CLEMENT" <gclement00@gmail.com> wrote:
> 2007/11/21, Josh Boyer <jwboyer@linux.vnet.ibm.com>:
> > On Wed, 21 Nov 2007 17:28:05 +0100
> > "Gregory CLEMENT" <gclement00@gmail.com> wrote:
> >
> > > 2007/11/21, Jörn Engel <joern@logfs.org>:
> > > > On Wed, 21 November 2007 15:27:19 +0100, Gregory CLEMENT wrote:
> > > > >
> > > > > I come back with my question because it seems that last time I sent
> > > > > this mail mtd mailing list was done during few weeks, so maybe this
> > > > > mail was lost.
> > > >
> > > > What problem does the driver solve?
> > > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > > embedded systems.
> >
> > Not really. It allows you to put one of those filesystems into
> > NAND using a bad-block aware program initially, and mount it. It
> > doesn't handle run-time bit flips or errors from what I can see.
> >
> > josh
> >
>
> Are these run-time bit flips can happen on reading only mode?
They can, yes. Particularly if you do lots of reads to the same NAND
page, which can happen for superblock type transactions.
josh
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 16:58 ` Josh Boyer
2007-11-21 17:07 ` Gregory CLEMENT
@ 2007-11-21 17:15 ` Jörn Engel
2007-11-21 17:32 ` Gregory CLEMENT
2007-11-21 17:43 ` Vitaly Wool
2007-11-21 20:46 ` Ricard Wanderlof
2 siblings, 2 replies; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 17:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linux-mtd, Jörn Engel, Gregory CLEMENT
On Wed, 21 November 2007 10:58:17 -0600, Josh Boyer wrote:
> > 2007/11/21, Jörn Engel <joern@logfs.org>:
> > >
> > > What problem does the driver solve?
> > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > embedded systems.
>
> Not really. It allows you to put one of those filesystems into
> NAND using a bad-block aware program initially, and mount it. It
> doesn't handle run-time bit flips or errors from what I can see.
Whether that is necessary I cannot tell. Maybe some people have
hardware where this isn't an issue.
But why yet another mtdblock driver? Is there a reason not to add the
required bits to mtdblock_ro.c?
Jörn
--
Correctness comes second.
Features come third.
Performance comes last.
Maintainability is easily forgotten.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:15 ` Jörn Engel
@ 2007-11-21 17:32 ` Gregory CLEMENT
2007-11-21 17:43 ` Vitaly Wool
1 sibling, 0 replies; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-21 17:32 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd
2007/11/21, Jörn Engel <joern@logfs.org>:
> On Wed, 21 November 2007 10:58:17 -0600, Josh Boyer wrote:
> > > 2007/11/21, Jörn Engel <joern@logfs.org>:
> > > >
> > > > What problem does the driver solve?
> > > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > > embedded systems.
> >
> > Not really. It allows you to put one of those filesystems into
> > NAND using a bad-block aware program initially, and mount it. It
> > doesn't handle run-time bit flips or errors from what I can see.
>
> Whether that is necessary I cannot tell. Maybe some people have
> hardware where this isn't an issue.
>
> But why yet another mtdblock driver? Is there a reason not to add the
> required bits to mtdblock_ro.c?
See the original thread for this:
it started here:
http://lists.infradead.org/pipermail/linux-mtd/2006-November/016835.html
and the question of a new driver was first discussed here:
http://lists.infradead.org/pipermail/linux-mtd/2006-November/016844.html
> Jörn
>
> --
> Correctness comes second.
> Features come third.
> Performance comes last.
> Maintainability is easily forgotten.
>
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:15 ` Jörn Engel
2007-11-21 17:32 ` Gregory CLEMENT
@ 2007-11-21 17:43 ` Vitaly Wool
2007-11-21 17:45 ` Jörn Engel
1 sibling, 1 reply; 33+ messages in thread
From: Vitaly Wool @ 2007-11-21 17:43 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, Gregory CLEMENT
On Nov 21, 2007 8:15 PM, Jörn Engel <joern@logfs.org> wrote:
> But why yet another mtdblock driver? Is there a reason not to add the
> required bits to mtdblock_ro.c?
Because we were explicitly directed by David to do so.
Vitaly
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:43 ` Vitaly Wool
@ 2007-11-21 17:45 ` Jörn Engel
2007-11-21 17:56 ` Vitaly Wool
0 siblings, 1 reply; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 17:45 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linux-mtd, Jörn Engel, Gregory CLEMENT
On Wed, 21 November 2007 20:43:14 +0300, Vitaly Wool wrote:
> On Nov 21, 2007 8:15 PM, Jörn Engel <joern@logfs.org> wrote:
> > But why yet another mtdblock driver? Is there a reason not to add the
> > required bits to mtdblock_ro.c?
>
> Because we were explicitly directed by David to do so.
And David has gone fishing. Did he tell you why?
Jörn
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:45 ` Jörn Engel
@ 2007-11-21 17:56 ` Vitaly Wool
2007-11-21 18:04 ` Jörn Engel
2007-11-23 14:35 ` Gregory CLEMENT
0 siblings, 2 replies; 33+ messages in thread
From: Vitaly Wool @ 2007-11-21 17:56 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, Gregory CLEMENT
On Nov 21, 2007 8:45 PM, Jörn Engel <joern@logfs.org> wrote:
> > Because we were explicitly directed by David to do so.
>
> And David has gone fishing. Did he tell you why?
He didn't want to add confusion, that's what he said. He directed us
to make it a separate translation layer an have a separate device
major (which we did get BTW :) ).
If there's no objections, I can rediff/repost against the current MTD
git. I'll also add some comments about the limitations of this
approach (still it's viable enough within a real environment if
there's an application which just reads the whole partition say once
in a week and rewrites it as soon as it detects bit error corrections;
that's what we did for emo BTW).
Vitaly
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:56 ` Vitaly Wool
@ 2007-11-21 18:04 ` Jörn Engel
2007-11-23 14:35 ` Gregory CLEMENT
1 sibling, 0 replies; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 18:04 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linux-mtd, Jörn Engel, Gregory CLEMENT
On Wed, 21 November 2007 20:56:03 +0300, Vitaly Wool wrote:
> On Nov 21, 2007 8:45 PM, Jörn Engel <joern@logfs.org> wrote:
> > > Because we were explicitly directed by David to do so.
> >
> > And David has gone fishing. Did he tell you why?
>
> He didn't want to add confusion, that's what he said.
That argument is little better than "because I say so". Oh well, I
simply don't care enough. Let him sort it out to his liking.
Jörn
--
Joern's library part 11:
http://www.unicom.com/pw/reply-to-harmful.html
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 16:58 ` Josh Boyer
2007-11-21 17:07 ` Gregory CLEMENT
2007-11-21 17:15 ` Jörn Engel
@ 2007-11-21 20:46 ` Ricard Wanderlof
2007-11-21 21:32 ` Jörn Engel
2007-11-22 13:08 ` Jamie Lokier
2 siblings, 2 replies; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-21 20:46 UTC (permalink / raw)
To: Linux mtd
On Wed, 21 Nov 2007, Josh Boyer wrote:
> > > What problem does the driver solve?
> > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > embedded systems.
>
> Not really. It allows you to put one of those filesystems into
> NAND using a bad-block aware program initially, and mount it. It
> doesn't handle run-time bit flips or errors from what I can see.
Won't ECC take care of spurious bit flips?
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 20:46 ` Ricard Wanderlof
@ 2007-11-21 21:32 ` Jörn Engel
2007-11-21 22:33 ` Gregory CLEMENT
2007-11-22 7:58 ` Ricard Wanderlof
2007-11-22 13:08 ` Jamie Lokier
1 sibling, 2 replies; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 21:32 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Linux mtd
On Wed, 21 November 2007 21:46:16 +0100, Ricard Wanderlof wrote:
> On Wed, 21 Nov 2007, Josh Boyer wrote:
>
> > > > What problem does the driver solve?
> > > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > > embedded systems.
> >
> > Not really. It allows you to put one of those filesystems into
> > NAND using a bad-block aware program initially, and mount it. It
> > doesn't handle run-time bit flips or errors from what I can see.
>
> Won't ECC take care of spurious bit flips?
Single-bit, yes. Once you accumulated a bunch of them in proximity, it
may no longer work.
Jörn
--
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 21:32 ` Jörn Engel
@ 2007-11-21 22:33 ` Gregory CLEMENT
2007-11-21 22:54 ` Jörn Engel
2007-11-22 7:58 ` Ricard Wanderlof
1 sibling, 1 reply; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-21 22:33 UTC (permalink / raw)
To: Jörn Engel; +Cc: Linux mtd, Ricard Wanderlof
2007/11/21, Jörn Engel <joern@logfs.org>:
> On Wed, 21 November 2007 21:46:16 +0100, Ricard Wanderlof wrote:
> > On Wed, 21 Nov 2007, Josh Boyer wrote:
> >
> > > > > What problem does the driver solve?
> > > > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > > > embedded systems.
> > >
> > > Not really. It allows you to put one of those filesystems into
> > > NAND using a bad-block aware program initially, and mount it. It
> > > doesn't handle run-time bit flips or errors from what I can see.
> >
> > Won't ECC take care of spurious bit flips?
>
> Single-bit, yes. Once you accumulated a bunch of them in proximity, it
> may no longer work.
That's mean that we can't have safe data on NAND flash device, isn't it?
If data is corrupted between tow read even journalized are log file
system will loose data.
Either there is a mechanism I missed in this file system or 2 bits
flipped are so rare that this event can be ignored.
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 22:33 ` Gregory CLEMENT
@ 2007-11-21 22:54 ` Jörn Engel
2007-11-22 7:58 ` Ricard Wanderlof
0 siblings, 1 reply; 33+ messages in thread
From: Jörn Engel @ 2007-11-21 22:54 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: Linux mtd, Jörn Engel, Ricard Wanderlof
On Wed, 21 November 2007 23:33:38 +0100, Gregory CLEMENT wrote:
>
> That's mean that we can't have safe data on NAND flash device, isn't it?
> If data is corrupted between tow read even journalized are log file
> system will loose data.
> Either there is a mechanism I missed in this file system or 2 bits
> flipped are so rare that this event can be ignored.
It means that NAND needs scrubbing.
Jörn
--
Joern's library part 3:
http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 21:32 ` Jörn Engel
2007-11-21 22:33 ` Gregory CLEMENT
@ 2007-11-22 7:58 ` Ricard Wanderlof
1 sibling, 0 replies; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-22 7:58 UTC (permalink / raw)
To: Linux mtd
On Wed, 21 Nov 2007, Jörn Engel wrote:
> > Won't ECC take care of spurious bit flips?
> Single-bit, yes. Once you accumulated a bunch of them in proximity, it
> may no longer work.
Yes that is true of course.
Does anyone know of any tests or evaluations run on NAND flash chips, more
than what can be found out from the data sheets?
We ran some tests on an ST 256 Mbit flash here to try and get some grip on
the various bit flipping mechanisms.
At least for this chip, it seemed that if a block has only been written a
few times, then there seems to be virtually no limit to how many times it
can be read without bit flips occurring (the test ran for three months
with continuous reading of the same block, during which over 4.5e+10
reads were performed). On the other hand, if the block was written the
maximum specified number of times (100 000 for this chip), bit flips would
start occurring after 15 million reads.
(We also wrote a block far over the specified limit, about 1.7 million
times. In this case, bit flips during read started occurring after about
200 000 reads.)
Of course, this was a random sample of a single chip type used in a
specific hardware environment, so it would be interesting to see if anyone
else has done any similar test.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 22:54 ` Jörn Engel
@ 2007-11-22 7:58 ` Ricard Wanderlof
2007-11-22 13:26 ` Jörn Engel
0 siblings, 1 reply; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-22 7:58 UTC (permalink / raw)
To: Linux mtd
On Wed, 21 Nov 2007, Jörn Engel wrote:
>> If data is corrupted between tow read even journalized are log file
>> system will loose data.
>> Either there is a mechanism I missed in this file system or 2 bits
>> flipped are so rare that this event can be ignored.
>
> It means that NAND needs scrubbing.
By 'scrubbing' do you mean erasing the blocks in question and rewriting
them with the same data in order to put fresh data back in the bit cells?
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 20:46 ` Ricard Wanderlof
2007-11-21 21:32 ` Jörn Engel
@ 2007-11-22 13:08 ` Jamie Lokier
1 sibling, 0 replies; 33+ messages in thread
From: Jamie Lokier @ 2007-11-22 13:08 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Linux mtd
Ricard Wanderlof wrote:
>
> On Wed, 21 Nov 2007, Josh Boyer wrote:
>
> > > > What problem does the driver solve?
> > > It allow to use cramfs/squashfs/fat in read-only on NAND flash for
> > > embedded systems.
> >
> > Not really. It allows you to put one of those filesystems into
> > NAND using a bad-block aware program initially, and mount it. It
> > doesn't handle run-time bit flips or errors from what I can see.
>
> Won't ECC take care of spurious bit flips?
Are the blocks written back after bit flips are detected?
If not, they will accumulate until they're uncorrectable.
-- Jamie
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-22 7:58 ` Ricard Wanderlof
@ 2007-11-22 13:26 ` Jörn Engel
2007-11-23 7:42 ` Ricard Wanderlof
0 siblings, 1 reply; 33+ messages in thread
From: Jörn Engel @ 2007-11-22 13:26 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Linux mtd
On Thu, 22 November 2007 08:58:58 +0100, Ricard Wanderlof wrote:
> On Wed, 21 Nov 2007, Jörn Engel wrote:
>
> >> If data is corrupted between tow read even journalized are log file
> >> system will loose data.
> >> Either there is a mechanism I missed in this file system or 2 bits
> >> flipped are so rare that this event can be ignored.
> >
> > It means that NAND needs scrubbing.
>
> By 'scrubbing' do you mean erasing the blocks in question and rewriting
> them with the same data in order to put fresh data back in the bit cells?
Please don't reply to the list only. If you are asking me a question,
it is really impolite to send it elsewhere. And I bet others would like
to stay on Cc: as well.
http://en.wikipedia.org/wiki/Memory_scrubbing
Trivial scrubbing could leave the block in an erased or
partially-written state if power-loss occurs at an inconvenient time.
So scrubbing should be performed in some higher layer like an FTL, a
filesystem, system maintenance applications, etc.
Jörn
--
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it.
-- Richard Feynman
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-22 13:26 ` Jörn Engel
@ 2007-11-23 7:42 ` Ricard Wanderlof
2007-11-23 8:18 ` Artem Bityutskiy
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-23 7:42 UTC (permalink / raw)
To: Jörn Engel; +Cc: Linux mtd
On Thu, 22 Nov 2007, Jörn Engel wrote:
> Please don't reply to the list only. If you are asking me a question,
> it is really impolite to send it elsewhere. And I bet others would like
> to stay on Cc: as well.
Sorry, no harm intended. (I tend to view discussions on a mailing list as
being on the mailing list, not between a couple of people with a cc to the
mailing list, because other people on the list should feel they can
respond to the questions posed. But either way is fine with me).
> http://en.wikipedia.org/wiki/Memory_scrubbing
Thanks for the link. I've never heard of the term being used for Flash
memory but of course it must apply there as well.
> Trivial scrubbing could leave the block in an erased or
> partially-written state if power-loss occurs at an inconvenient time.
> So scrubbing should be performed in some higher layer like an FTL, a
> filesystem, system maintenance applications, etc.
In the case of mtd, it would seem that this should be done by JFFS2, or if
some intermediate layer is used like UBI, by that layer. As far as I know
though, currently no scrubbing is done by either?
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 7:42 ` Ricard Wanderlof
@ 2007-11-23 8:18 ` Artem Bityutskiy
2007-11-23 9:08 ` Ricard Wanderlof
2007-11-23 8:19 ` Artem Bityutskiy
2007-11-23 12:46 ` Jörn Engel
2 siblings, 1 reply; 33+ messages in thread
From: Artem Bityutskiy @ 2007-11-23 8:18 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Jörn Engel, Linux mtd
Hi Ricard,
On Fri, 2007-11-23 at 08:42 +0100, Ricard Wanderlof wrote:
> In the case of mtd, it would seem that this should be done by JFFS2, or if
> some intermediate layer is used like UBI, by that layer. As far as I know
> though, currently no scrubbing is done by either?
Nope, scrubbing was one of the design goals of UBI and it does do it.
If mtd_read() returns -EUCLEAN, which means a correctable ECC error
occurred (bit-flip), UBI schedules this physical eraseblock for
movement. Then it moves it in background, re-maps corresponding logical
eraseblock to the new physical eraseblock, and schedules the old
physical eraseblock for erasure.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 7:42 ` Ricard Wanderlof
2007-11-23 8:18 ` Artem Bityutskiy
@ 2007-11-23 8:19 ` Artem Bityutskiy
2007-11-23 12:46 ` Jörn Engel
2 siblings, 0 replies; 33+ messages in thread
From: Artem Bityutskiy @ 2007-11-23 8:19 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Jörn Engel, Linux mtd
On Fri, 2007-11-23 at 08:42 +0100, Ricard Wanderlof wrote:
> In the case of mtd, it would seem that this should be done by JFFS2, or if
> some intermediate layer is used like UBI, by that layer. As far as I know
> though, currently no scrubbing is done by either?
And yes, JFFS2 does not do this.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 8:18 ` Artem Bityutskiy
@ 2007-11-23 9:08 ` Ricard Wanderlof
2007-11-23 9:21 ` Artem Bityutskiy
0 siblings, 1 reply; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-23 9:08 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: Jörn Engel, Linux mtd
> On Fri, 23 Nov 2007, Artem Bityutskiy wrote:
>
> Nope, scrubbing was one of the design goals of UBI and it does do it.
That's good news!
> If mtd_read() returns -EUCLEAN, which means a correctable ECC error
> occurred (bit-flip), UBI schedules this physical eraseblock for
> movement. Then it moves it in background, re-maps corresponding logical
> eraseblock to the new physical eraseblock, and schedules the old
> physical eraseblock for erasure.
Does UBI periodically scan the flash for bit flips, or is the scrubbing
mechanism only triggered when an mtd_read() is done by a higher layer?
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 9:08 ` Ricard Wanderlof
@ 2007-11-23 9:21 ` Artem Bityutskiy
2007-11-23 9:28 ` Ricard Wanderlof
0 siblings, 1 reply; 33+ messages in thread
From: Artem Bityutskiy @ 2007-11-23 9:21 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Jörn Engel, Linux mtd
On Fri, 2007-11-23 at 10:08 +0100, Ricard Wanderlof wrote:
> Does UBI periodically scan the flash for bit flips, or is the scrubbing
> mechanism only triggered when an mtd_read() is done by a higher layer?
No, it does not do any background scanning for bit-flips. The second is
true.
If one needs some scanning, it may be implemented by making a
users-space script run by cron daemon I guess.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 9:21 ` Artem Bityutskiy
@ 2007-11-23 9:28 ` Ricard Wanderlof
2007-11-23 18:40 ` David Brown
0 siblings, 1 reply; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-23 9:28 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: Jörn Engel, Linux mtd
On Fri, 23 Nov 2007, Artem Bityutskiy wrote:
> On Fri, 2007-11-23 at 10:08 +0100, Ricard Wanderlof wrote:
>> Does UBI periodically scan the flash for bit flips, or is the scrubbing
>> mechanism only triggered when an mtd_read() is done by a higher layer?
>
> No, it does not do any background scanning for bit-flips. The second is
> true.
>
> If one needs some scanning, it may be implemented by making a
> users-space script run by cron daemon I guess.
On second thought, I think that the degradation of the data in a
flash memory cell is mostly due to read operations, so if no read
operations are performed, the data should be fairly secure. Then again,
there are subtle effects such as cosmic radiation flipping bits at any
random location, etc.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 7:42 ` Ricard Wanderlof
2007-11-23 8:18 ` Artem Bityutskiy
2007-11-23 8:19 ` Artem Bityutskiy
@ 2007-11-23 12:46 ` Jörn Engel
2 siblings, 0 replies; 33+ messages in thread
From: Jörn Engel @ 2007-11-23 12:46 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Jörn Engel, Linux mtd
On Fri, 23 November 2007 08:42:16 +0100, Ricard Wanderlof wrote:
> On Thu, 22 Nov 2007, Jörn Engel wrote:
>
> > Please don't reply to the list only. If you are asking me a question,
> > it is really impolite to send it elsewhere. And I bet others would like
> > to stay on Cc: as well.
>
> Sorry, no harm intended. (I tend to view discussions on a mailing list as
> being on the mailing list, not between a couple of people with a cc to the
> mailing list, because other people on the list should feel they can
> respond to the questions posed. But either way is fine with me).
Some discussions are on several mailing lists. Some people like me
regularly read about a dozen mailing lists. Linux-kernel alone accounts
for nearly 400 mails a day. Some people "read" mailing lists with the
'D' key and only occasionally stop when spotting something interesting.
Since I moved to my own server about a year ago, I received 1.3GB of
mail, not counting spam.
The only reasonably sane strategy I know is to simply reply to all and
not worry about the size of the Cc: list. If the discussion was private
before, it remains private. If it was public, it remains public.
Jörn
--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-21 17:56 ` Vitaly Wool
2007-11-21 18:04 ` Jörn Engel
@ 2007-11-23 14:35 ` Gregory CLEMENT
2007-11-23 14:45 ` Jörn Engel
1 sibling, 1 reply; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-23 14:35 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linux-mtd, Jörn Engel
2007/11/21, Vitaly Wool <vitalywool@gmail.com>:
> On Nov 21, 2007 8:45 PM, Jörn Engel <joern@logfs.org> wrote:
> > > Because we were explicitly directed by David to do so.
> >
> > And David has gone fishing. Did he tell you why?
>
> He didn't want to add confusion, that's what he said. He directed us
> to make it a separate translation layer an have a separate device
> major (which we did get BTW :) ).
>
> If there's no objections, I can rediff/repost against the current MTD
> git. I'll also add some comments about the limitations of this
> approach (still it's viable enough within a real environment if
> there's an application which just reads the whole partition say once
> in a week and rewrites it as soon as it detects bit error corrections;
> that's what we did for emo BTW).
As it seems that there is no objections on it, can you push the patch in mtd ?
I have to made some change to apply the patch on 2.6.23 kernel, if ti
can help you, I join the new patch.
I test it on my board it seems working pretty well.
But I have a question, why mtdblock and romblock were mutually
exclusive? I guess it is to avoid the same mtd partition mounted both
time. Can't we deal with this case?
Index: drivers/mtd/Kconfig
===================================================================
--- drivers/mtd/Kconfig
+++ drivers/mtd/Kconfig
@@ -200,6 +200,13 @@
You do not need this option for use with the DiskOnChip devices. For
those, enable NFTL support (CONFIG_NFTL) instead.
+config MTD_BLOCK_ROMBLOCK
+ tristate "Readonly Block Device Layer Over MTD"
+ depends on MTD
+ help
+ Same as readonly block driver, but this allow you to mount
read-only file
+ systems from an MTD device, containing bad blocks.
+
config FTL
tristate "FTL (Flash Translation Layer) support"
depends on BLOCK
Index: drivers/mtd/romblock.c
===================================================================
--- drivers/mtd/romblock.c
+++ drivers/mtd/romblock.c
@@ -0,0 +1,164 @@
+/*
+ * Readonly Block Device Layer Over MTD
+ *
+ * (C) 2006 Baydarov Konstantin <kbaidarov@dev.rtsoft.ru>
+ * Pantelis Antoniou <panto@intracom.gr>
+ * David Woodhouse <dwmw2@infradead.org>
+ *
+ * It allows to use any filesystem on this device in
+ * RO mode and thus gain faster mount times and better
+ * throughput rates.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/blktrans.h>
+
+struct romblock_map {
+ struct mtd_blktrans_dev dev;
+ /* block map for RO */
+ int32_t *block_map;
+ int32_t block_top;
+ int32_t block_scantop;
+};
+
+static loff_t map_over_bad_blocks(struct mtd_blktrans_dev* dev, loff_t from)
+{
+ int i, block;
+ struct mtd_info *mtd = dev->mtd;
+ struct romblock_map* dev_cont = container_of(dev, struct
romblock_map, dev);
+ int32_t *block_map = dev_cont->block_map;
+ int32_t block_top = dev_cont->block_top;
+ int32_t block_scantop = dev_cont->block_scantop;
+
+ /* if no bad block checking is possible bail out */
+ if (mtd->block_isbad == NULL)
+ return from;
+
+ /* first time in */
+ if (block_map == NULL) {
+ block_top = mtd->size / mtd->erasesize;
+
+ block_map = kmalloc(sizeof(*block_map) * block_top, GFP_KERNEL);
+ if (block_map == NULL) {
+ printk (KERN_ERR "map_over_bad_blocks():
unable to allocate block map\n");
+ return -ENOMEM;
+ }
+ for (i = 0; i < block_top; i++)
+ block_map[i] = -1;
+
+ for (i = 0; i < block_top; i++)
+ if ((*mtd->block_isbad)(mtd, i * mtd->erasesize) == 0)
+ break;
+
+ if (i >= block_top) {
+ printk (KERN_WARNING "map_over_bad_blocks():
all blocks bad!\n");
+ return -EIO;
+ }
+ block_scantop = 0;
+ block_map[0] = i;
+
+ DEBUG(MTD_DEBUG_LEVEL0, "mtd: map %d -> %d\n",
block_scantop, block_map[block_scantop]);
+ }
+
+ block = ((int)from / mtd->erasesize);
+ if (block >= block_top)
+ return (loff_t)-1;
+
+ /* scan for bad block up to where we want */
+ while (block >= block_scantop) {
+ /* find a non bad block */
+ for (i = block_map[block_scantop] + 1; i < block_top; i++)
+ if ((*mtd->block_isbad)(mtd, i * mtd->erasesize) == 0)
+ break;
+
+ /* exhausted ? */
+ if (i >= block_top) {
+ printk (KERN_WARNING "map_over_bad_blocks():
no more good blocks!\n");
+ return (loff_t)-1;
+ }
+
+ block_map[++block_scantop] = i;
+ DEBUG(MTD_DEBUG_LEVEL0, "mtd: map %d -> %d\n",
block_scantop, block_map[block_scantop]);
+ }
+
+ block = block_map[(int)from / mtd->erasesize];
+ from = (block * mtd->erasesize) | ((int)from & (mtd->erasesize - 1));
+ return from;
+}
+
+static int romblock_readsect(struct mtd_blktrans_dev *dev,
+ unsigned long block, char *buf)
+{
+ size_t retlen;
+ unsigned long from;
+
+ from = map_over_bad_blocks(dev, block<<9);
+
+ if (dev->mtd->read(dev->mtd, from, 512, &retlen, buf))
+ return 1;
+ return 0;
+}
+
+static int romblock_writesect(struct mtd_blktrans_dev *dev,
+ unsigned long block, char *buf)
+{
+ size_t retlen;
+
+ if (dev->mtd->write(dev->mtd, (block * 512), 512, &retlen, buf))
+ return 1;
+ return 0;
+}
+
+static void romblock_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
+{
+ struct romblock_map *dev_cont = kzalloc(sizeof(*dev_cont), GFP_KERNEL);
+
+ if (!dev_cont)
+ return;
+
+ dev_cont->dev.mtd = mtd;
+ dev_cont->dev.devnum = mtd->index;
+ dev_cont->dev.size = mtd->size >> 9;
+ dev_cont->dev.tr = tr;
+ dev_cont->dev.readonly = 1;
+
+ add_mtd_blktrans_dev(&(dev_cont->dev));
+}
+
+static void romblock_remove_dev(struct mtd_blktrans_dev *dev)
+{
+ del_mtd_blktrans_dev(dev);
+ kfree(dev);
+}
+
+static struct mtd_blktrans_ops romblock_tr = {
+ .name = "romblock",
+ .major = 258,
+ .part_bits = 0,
+ .blksize = 512,
+ .readsect = romblock_readsect,
+ .writesect = romblock_writesect,
+ .add_mtd = romblock_add_mtd,
+ .remove_dev = romblock_remove_dev,
+ .owner = THIS_MODULE,
+};
+
+static int __init romblock_init(void)
+{
+ return register_mtd_blktrans(&romblock_tr);
+}
+
+static void __exit romblock_exit(void)
+{
+ deregister_mtd_blktrans(&romblock_tr);
+}
+
+module_init(romblock_init);
+module_exit(romblock_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Baydarov Konstantin <kbaidarov@dev.rtsoft.ru>");
+MODULE_DESCRIPTION("Readonly Block Device Layer Over MTD");
Index: drivers/mtd/Makefile
===================================================================
--- drivers/mtd/Makefile
+++ drivers/mtd/Makefile
@@ -17,6 +17,7 @@
obj-$(CONFIG_MTD_BLKDEVS) += mtd_blkdevs.o
obj-$(CONFIG_MTD_BLOCK) += mtdblock.o
obj-$(CONFIG_MTD_BLOCK_RO) += mtdblock_ro.o
+obj-$(CONFIG_MTD_BLOCK_ROMBLOCK) += romblock.o mtd_blkdevs.o
obj-$(CONFIG_FTL) += ftl.o
obj-$(CONFIG_NFTL) += nftl.o
obj-$(CONFIG_INFTL) += inftl.o
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 14:35 ` Gregory CLEMENT
@ 2007-11-23 14:45 ` Jörn Engel
2007-11-23 15:06 ` Gregory CLEMENT
0 siblings, 1 reply; 33+ messages in thread
From: Jörn Engel @ 2007-11-23 14:45 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: linux-mtd, Jörn Engel, Vitaly Wool
On Fri, 23 November 2007 15:35:17 +0100, Gregory CLEMENT wrote:
>
> As it seems that there is no objections on it, can you push the patch in mtd ?
I do object against your patch on formal grounds. It lacks:
o a useful description,
o Signed-off-by:,
o diffstat,
o diff -up (you just had -u),
and maybe some more.
Also please fix your mailer so it doesn't word-wrap the patch. I won't
read it in its current state.
You might want to start reading Documentation/Submit* about now. ;)
Jörn
--
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by
Raph Levien, 1979
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 14:45 ` Jörn Engel
@ 2007-11-23 15:06 ` Gregory CLEMENT
0 siblings, 0 replies; 33+ messages in thread
From: Gregory CLEMENT @ 2007-11-23 15:06 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, Vitaly Wool
2007/11/23, Jörn Engel <joern@logfs.org>:
> On Fri, 23 November 2007 15:35:17 +0100, Gregory CLEMENT wrote:
> >
> > As it seems that there is no objections on it, can you push the patch in mtd ?
>
> I do object against your patch on formal grounds. It lacks:
> o a useful description,
> o Signed-off-by:,
> o diffstat,
> o diff -up (you just had -u),
> and maybe some more.
In fact this patch was not aimed to be directly included in mtd, but
just to help Vitaly to generate his patch as he offered to generate it
with git. It also seems that he know this patch pretty well and he
could make a better description than me!
>
> Also please fix your mailer so it doesn't word-wrap the patch. I won't
> read it in its current state.
I hopped that google mail was more patch friendly, I was wrong. So I
can't send it inline before tonight at home, but if you don't mind I
can attach it.
>
> You might want to start reading Documentation/Submit* about now. ;)
>
> Jörn
>
> --
> Don't worry about people stealing your ideas. If your ideas are any good,
> you'll have to ram them down people's throats.
> -- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by
> Raph Levien, 1979
>
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 9:28 ` Ricard Wanderlof
@ 2007-11-23 18:40 ` David Brown
2007-11-26 9:42 ` Ricard Wanderlof
0 siblings, 1 reply; 33+ messages in thread
From: David Brown @ 2007-11-23 18:40 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Jörn Engel, Linux mtd
On Fri, Nov 23, 2007 at 10:28:24AM +0100, Ricard Wanderlof wrote:
>On second thought, I think that the degradation of the data in a
>flash memory cell is mostly due to read operations, so if no read
>operations are performed, the data should be fairly secure. Then again,
>there are subtle effects such as cosmic radiation flipping bits at any
>random location, etc.
Flash should be reasonably immune to degradation from reads. In fact, it
is fairly resiliant to degradation at all.
In NAND, the primary cause of read failures is caused by writes (and
rewrites) of subsequent pages within a block. These can cause bit flips in
earlier written pages. This gets worse with higher density, and is the
main reason the higher density devices have greater restrictions on
rewrites.
David
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-23 18:40 ` David Brown
@ 2007-11-26 9:42 ` Ricard Wanderlof
2007-11-26 13:58 ` Claudio Lanconelli
0 siblings, 1 reply; 33+ messages in thread
From: Ricard Wanderlof @ 2007-11-26 9:42 UTC (permalink / raw)
To: David Brown; +Cc: Jörn Engel, Linux mtd
On Fri, 23 Nov 2007, David Brown wrote:
> Flash should be reasonably immune to degradation from reads. In fact,
> it is fairly resiliant to degradation at all.
I beg to differ; we ran some tests here on a 256 Mbit NAND flash where I
work which showed a marked degradation in read integrity if the block had
been written many times. For this particular chip in the setup used, after
100 000 read/write cycles, non-correctable ECC errors started popping up
after about 43 million reads. For blocks that had only been written a
couple of times, we didn't detect any read errors whatsoever after 4.5e+10
reads (during three months of continuous reading of the same block).
I would however love to see some hard data, or at least an application
note, on the frequency of various errors. Most of the information I've
seen is of the 'it is a known fact that ...' - type, without any
references. And the data sheets seem very silent on this subject, only
acknowledging the fact that bit flips do occur.
> In NAND, the primary cause of read failures is caused by writes (and
> rewrites) of subsequent pages within a block. These can cause bit flips in
> earlier written pages. This gets worse with higher density, and is the
> main reason the higher density devices have greater restrictions on
> rewrites.
This is very interesting. This is something we did not address during our
tests mentioned above.
It implies that having a device partitioned into a read-only and a
read-write partition, would have very few bit flips occurring in the
read-only partition even if the read-write partition was rewritten very
frequently (since partitions must be multiples of the block size).
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
2007-11-26 9:42 ` Ricard Wanderlof
@ 2007-11-26 13:58 ` Claudio Lanconelli
0 siblings, 0 replies; 33+ messages in thread
From: Claudio Lanconelli @ 2007-11-26 13:58 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: David Brown, Linux mtd
Ricard Wanderlof wrote:
> On Fri, 23 Nov 2007, David Brown wrote:
>
>
>> Flash should be reasonably immune to degradation from reads. In fact,
>> it is fairly resiliant to degradation at all.
>>
>
> I beg to differ; we ran some tests here on a 256 Mbit NAND flash where I
> work which showed a marked degradation in read integrity if the block had
> been written many times. For this particular chip in the setup used, after
> 100 000 read/write cycles, non-correctable ECC errors started popping up
> after about 43 million reads. For blocks that had only been written a
> couple of times, we didn't detect any read errors whatsoever after 4.5e+10
> reads (during three months of continuous reading of the same block).
>
> I would however love to see some hard data, or at least an application
> note, on the frequency of various errors. Most of the information I've
> seen is of the 'it is a known fact that ...' - type, without any
> references. And the data sheets seem very silent on this subject, only
> acknowledging the fact that bit flips do occur.
>
Hi,
I find very useful this paper, it talks about "read disturb" on page 22:
http://www.edn.com/contents/images/ToshibaNANDFlash1.pdf
Cheers,
Claudio Lanconelli
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2007-11-26 14:00 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-21 14:27 Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ? Gregory CLEMENT
2007-11-21 16:08 ` Jörn Engel
2007-11-21 16:28 ` Gregory CLEMENT
2007-11-21 16:58 ` Josh Boyer
2007-11-21 17:07 ` Gregory CLEMENT
2007-11-21 17:13 ` Josh Boyer
2007-11-21 17:15 ` Jörn Engel
2007-11-21 17:32 ` Gregory CLEMENT
2007-11-21 17:43 ` Vitaly Wool
2007-11-21 17:45 ` Jörn Engel
2007-11-21 17:56 ` Vitaly Wool
2007-11-21 18:04 ` Jörn Engel
2007-11-23 14:35 ` Gregory CLEMENT
2007-11-23 14:45 ` Jörn Engel
2007-11-23 15:06 ` Gregory CLEMENT
2007-11-21 20:46 ` Ricard Wanderlof
2007-11-21 21:32 ` Jörn Engel
2007-11-21 22:33 ` Gregory CLEMENT
2007-11-21 22:54 ` Jörn Engel
2007-11-22 7:58 ` Ricard Wanderlof
2007-11-22 13:26 ` Jörn Engel
2007-11-23 7:42 ` Ricard Wanderlof
2007-11-23 8:18 ` Artem Bityutskiy
2007-11-23 9:08 ` Ricard Wanderlof
2007-11-23 9:21 ` Artem Bityutskiy
2007-11-23 9:28 ` Ricard Wanderlof
2007-11-23 18:40 ` David Brown
2007-11-26 9:42 ` Ricard Wanderlof
2007-11-26 13:58 ` Claudio Lanconelli
2007-11-23 8:19 ` Artem Bityutskiy
2007-11-23 12:46 ` Jörn Engel
2007-11-22 7:58 ` Ricard Wanderlof
2007-11-22 13:08 ` Jamie Lokier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox