public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@avtrex.com>
To: Pantelis Antoniou <panto@intracom.gr>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [patch] Allow any filesystem on MTD Nand when Read Only
Date: Wed, 05 May 2004 08:26:16 -0700	[thread overview]
Message-ID: <40990798.9020703@avtrex.com> (raw)
In-Reply-To: <4098DF0D.1040703@intracom.gr>

Pantelis Antoniou wrote:

> Hello there.
>
> The following patch allows you to have any filesystem over NAND when 
> mounted
> read only.
>
> The main drive for this was that I wanted to use CRAMFS over NAND 
> flash since
> it has a much higher compression ratio than JFFS2.
>
> How it works is pretty simple.
>
> It's pretty reasonable assumption that bad blocks are created only when
> writting to NAND. So in the read-only case it is possible to skip over 
> the bad
> blocks and offer a bad-block free block device to the upper layers.
> This allows us to utilize any filesystem when  read-only.
>
> In order to speed the mount operation the bad block detection is 
> performed lazilly.
>
> Using the patch I was able to mount as read-only CRAMFS/JFFS2 partitions
> which contained simulated bad-blocks.
>
> Awaiting your comments...
>
> Regards
>
> Pantelis
>
After more thought, I am in the process of doing something similar.

However my changes are not quite done yet.  Roughly it goes like this:

Write a new read-only block driver that skips bad blocks and uses ECC 
reads.  This allows any read only file system to use it (ie cramfs).  
The bad block map is kept in the first non-bad page in the partition, 
when the driver is installed it reads the bad block map.

To write the data into the mtd, you have a special version of nandwrite 
that checks for bad blocks while writing the image and finally writes 
the bad block map.

One difference between my approach and yours is that no existing mtd 
driver code is touched, it is simply another mtd block driver.

David Daney.

  parent reply	other threads:[~2004-05-05 15:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-05 12:33 [patch] Allow any filesystem on MTD Nand when Read Only Pantelis Antoniou
2004-05-05 12:57 ` David Woodhouse
2004-05-05 13:03   ` Pantelis Antoniou
2004-05-05 15:26 ` David Daney [this message]
2004-05-05 17:44   ` Phillip Lougher
2004-05-05 19:07     ` David Daney
2004-05-06  7:12     ` Pantelis Antoniou
     [not found] <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
2004-05-06  7:20 ` Pantelis Antoniou
2004-05-06  8:02   ` Thomas Gleixner
     [not found] <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
2004-05-06  9:39 ` Pantelis Antoniou
2004-05-06  9:48 ` Thomas Gleixner
2004-05-06  9:45   ` Pantelis Antoniou

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=40990798.9020703@avtrex.com \
    --to=ddaney@avtrex.com \
    --cc=dwmw2@infradead.org \
    --cc=panto@intracom.gr \
    /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