public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: Jasmine Strong <jasmine@regolith.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Cram FS on NAND - How to do this?
Date: Wed, 11 Jun 2003 12:54:58 +0300	[thread overview]
Message-ID: <3EE6FC72.10107@intracom.gr> (raw)
In-Reply-To: <4A3DE310-9BEB-11D7-B76F-000393AD6294@regolith.co.uk>

Jasmine Strong wrote:

>
> On Wednesday, Jun 11, 2003, at 09:43 Europe/London, Pantelis Antoniou 
> wrote:
> [snip]
>
> 1)  Where are you going to store this bad block list?
>
> There isn't anywhere on the Flash that can be guaranteed good.
> You can't pick a set location for the bad block list, so you must scan
> for it-  and once you have found it you must have some way to
> check that you are looking at a good copy of it.
>
> If you plan to generate it at mount time, you run the risk that
> a block has gone bad while the device has been dormant, and
> thus you may generate a block list that does not match the one
> the device was written with,  which could render a block
> -structured filesystem like cramfs unreadable.
>
> Also, all this scanning takes time, which makes mounting slow.

I'm talking about a read only filesystem, and generating
the bad block info at mount time.

Perhaps I could also use some kind of lazy bad block scanning technique
in which the list would only be generated up to point where
someone requested a read.

Well, and if a block goes bad what was written as good there
is nothing any filesystem can do but die complaining.

>
> 2)  What about blocks that go bad while the system is in service?
>
> Flash blocks go bad randomly, and often while they are in use.
> You must use a strategy to cope with this-  JFFS and YAFFS use
> Reed-Solomon forward error correction.

Well, blocks go bad generally at writting, something that is
quite rare at a read only filesystem.
As for error correction I won't reinvent the wheel, I'll use the
JFFS2 error correction.

>
> 3)  What about wear-levelling?
>
> Flash blocks do not last indefinitely.  Every erase brings the Flash
> block you are erasing closer to the end of its lifespan.  Obviously
> this is less of a concern on a static filesystem like cramfs.
>
> Why not put a cramfs filesystem into a file on a YAFFS or JFFS2
> filesystem and use a loopback to mount it?
>
> -Jas.
>
>
>
Again, no need for that on a read-only filesystem. The number of erases
I expect during the life of the device is lower than 100.

And using the loopback trick is impossible for the root filesystem.

Anyway thanks for the input.

Regards

Pantelis

  reply	other threads:[~2003-06-11  9:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-11  8:43 Cram FS on NAND - How to do this? Pantelis Antoniou
2003-06-11  8:51 ` David Woodhouse
2003-06-11  8:58   ` Pantelis Antoniou
2003-06-11  9:04     ` David Woodhouse
2003-06-11  9:10       ` Russ Dill
2003-06-11  9:12         ` David Woodhouse
2003-06-11  9:01 ` Jasmine Strong
2003-06-11  9:54   ` Pantelis Antoniou [this message]
2003-06-11 10:24     ` angainor
2003-06-11 19:22     ` Russ Dill
2003-06-12  8:22       ` Pantelis Antoniou
2003-06-12  9:06 ` Thomas Gleixner
2003-06-12  8:15   ` Pantelis Antoniou
2003-06-12 23:13 ` Charles Manning
2003-06-13 12:18   ` Jasmine Strong
2003-06-13 16:30     ` Brian J. Fox
2003-06-13 16:33       ` Jasmine Strong
2003-06-13 16:45         ` Brian J. Fox

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=3EE6FC72.10107@intracom.gr \
    --to=panto@intracom.gr \
    --cc=jasmine@regolith.co.uk \
    --cc=linux-mtd@lists.infradead.org \
    /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