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.
next prev 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