Cram FS on NAND - How to do this?

Cram FS on NAND - How to do this?

[Pantelis Antoniou]

Hi

As it currently stands the only filesystems supporting
raw NAND flash are:

JFFS2: Read/write, compressed, best support, slow startup.
YAFFS: Read/write, not compressed, newcomer, fast startup.

I have a requirement to have a compressed read only
root filesystem in my board and I've come to the
conclussion that the best fit would be CRAMFS if only
had any concept of bad blocks.

Looking at the code for CRAMFS I see that it would not
be very difficult to hack it to detect the bad blocks
and skip over them on startup. We could rely on
the same OOB info that JFFS2 has, and just
make a mapping list as follows:

NAND block  bad?  fs block
----------  ----  --------
    0         n      0
    1         n      1
    2         y     skip
    3         n      2

... etc

The first complication is that CRAMFS works with
PAGE_SIZE blocks only, and that should be taken
into account.

The second is that this is the first time I hack filesystem
code and I would like to ask the list if you see any difficulties
ahead.

What are your thoughts in this?

Regards

Pantelis

Re: Cram FS on NAND - How to do this?

[David Woodhouse]

On Wed, 2003-06-11 at 09:43, Pantelis Antoniou wrote:
> Hi
> 
> As it currently stands the only filesystems supporting
> raw NAND flash are:
> 
> JFFS2: Read/write, compressed, best support, slow startup.
> YAFFS: Read/write, not compressed, newcomer, fast startup.
> 
> I have a requirement to have a compressed read only
> root filesystem in my board and I've come to the
> conclussion that the best fit would be CRAMFS if only
> had any concept of bad blocks.

I think it would probably be better to implement this as a block device
driver, or perhaps as an extension to the existing mtdblock/mtdblock_ro
drivers.

-- 
dwmw2

Re: Cram FS on NAND - How to do this?

[Pantelis Antoniou]

David Woodhouse wrote:

>On Wed, 2003-06-11 at 09:43, Pantelis Antoniou wrote:
>
>>Hi
>>
>>As it currently stands the only filesystems supporting
>>raw NAND flash are:
>>
>>JFFS2: Read/write, compressed, best support, slow startup.
>>YAFFS: Read/write, not compressed, newcomer, fast startup.
>>
>>I have a requirement to have a compressed read only
>>root filesystem in my board and I've come to the
>>conclussion that the best fit would be CRAMFS if only
>>had any concept of bad blocks.
>>
>
>I think it would probably be better to implement this as a block device
>driver, or perhaps as an extension to the existing mtdblock/mtdblock_ro
>drivers.
>
>
That is a valid approach.

I take it that you mean a new MTD block device over NAND that
automatically skips over bad blocks and presents an error free
block interface for use by read only filesystems.

Thanks, it really pays off to ask questions first, and hack afterwards ;)

Regards

Pantelis

Re: Cram FS on NAND - How to do this?

[David Woodhouse]

On Wed, 2003-06-11 at 09:58, Pantelis Antoniou wrote:
> That is a valid approach.
> 
> I take it that you mean a new MTD block device over NAND that
> automatically skips over bad blocks and presents an error free
> block interface for use by read only filesystems.

Basically, yes. You can then either require the use of a special
userspace tool to program the file system images onto the flash, or
perhaps you could implement it as a writable block device, in the
expectation that people don't _actually_ use it in write mode in
production.

-- 
dwmw2

Re: Cram FS on NAND - How to do this?

[Russ Dill]

On Wed, 2003-06-11 at 02:04, David Woodhouse wrote:
> On Wed, 2003-06-11 at 09:58, Pantelis Antoniou wrote:
> > That is a valid approach.
> > 
> > I take it that you mean a new MTD block device over NAND that
> > automatically skips over bad blocks and presents an error free
> > block interface for use by read only filesystems.
> 
> Basically, yes. You can then either require the use of a special
> userspace tool to program the file system images onto the flash, or
> perhaps you could implement it as a writable block device, in the
> expectation that people don't _actually_ use it in write mode in
> production.

you could simplify this by making it so that writes can only occur
starting at 0 sequentially onward (I think this is doable by not
implementing seek)

-- 
Russ Dill <Russ.Dill@asu.edu>

Re: Cram FS on NAND - How to do this?

[David Woodhouse]

On Wed, 2003-06-11 at 10:10, Russ Dill wrote:
> you could simplify this by making it so that writes can only occur
> starting at 0 sequentially onward (I think this is doable by not
> implementing seek)

Not the case for block devices. With the mtd_blkdevs helper stuff I
implemented a week or so ago, you just provide 'readsector()' and
'writesector()' routines.

-- 
dwmw2

Re: Cram FS on NAND - How to do this?

[Jasmine Strong]

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.

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.

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.

Re: Cram FS on NAND - How to do this?

[Pantelis Antoniou]

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

Re: Cram FS on NAND - How to do this?

[angainor]

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

Not so impossible ;) You could load the kernel and do the mount
within initrd, then pivot_root / chroot.

Cheers

Marcin

Re: Cram FS on NAND - How to do this?

[Russ Dill]

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

Bad blocks would be generated at FS creation time, but as time goes on,
some blocks may start going bad. May not be important for 5 or 6
devices, but when you go into production with 100+ devices, this would
become important. Once a block goes bad, but the data is recoverable
with ECC, you'd want to relocate the block at the end of the FS and note
it somehow..

or not:

An index is in each oob, for the first n (where n is the size of the FS)
blocks, the index is just the block number. After that, if a block is
found bad while writing the FS, or during usage, that block is rewritten
past the end of the FS in the "reserve area" with the index number of
that block.

At mount time, the only scanning that would need to be done is in the
reserve area.


-- 
Russ Dill <Russ.Dill@asu.edu>

Re: Cram FS on NAND - How to do this?

[Pantelis Antoniou]

Russ Dill wrote:

>>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.
>>    
>>
>
>Bad blocks would be generated at FS creation time, but as time goes on,
>some blocks may start going bad. May not be important for 5 or 6
>devices, but when you go into production with 100+ devices, this would
>become important. Once a block goes bad, but the data is recoverable
>with ECC, you'd want to relocate the block at the end of the FS and note
>it somehow..
>  
>
I am aware of the problem when going into production with a large
number of devices.

I'm not really sure however about how widespread the problem will that be.

Has anybody collected any data on the problem?
How often does it happen to write a block to the chip, verify that it was
written correctly without ecc errors, and then happen to read it
back with one bit error.

>or not:
>
>An index is in each oob, for the first n (where n is the size of the FS)
>blocks, the index is just the block number. After that, if a block is
>found bad while writing the FS, or during usage, that block is rewritten
>past the end of the FS in the "reserve area" with the index number of
>that block.
>
>At mount time, the only scanning that would need to be done is in the
>reserve area.
>
>
Hey, that is clever.
I'll see what I can do..

Regards

Pantelis

Re: Cram FS on NAND - How to do this?

[Thomas Gleixner]

On Wednesday 11 June 2003 10:43, Pantelis Antoniou wrote:
> Hi
>
> I have a requirement to have a compressed read only
> root filesystem in my board and I've come to the
> conclussion that the best fit would be CRAMFS if only
> had any concept of bad blocks.

Why don't you use a JFFS2 partition and mount it read only ?
Then you have a compressed read only root filesystem.
All there no hacking required. :)
 
-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Cram FS on NAND - How to do this?

[Pantelis Antoniou]

Thomas Gleixner wrote:

>On Wednesday 11 June 2003 10:43, Pantelis Antoniou wrote:
>
>>Hi
>>
>>I have a requirement to have a compressed read only
>>root filesystem in my board and I've come to the
>>conclussion that the best fit would be CRAMFS if only
>>had any concept of bad blocks.
>>
>
>Why don't you use a JFFS2 partition and mount it read only ?
>Then you have a compressed read only root filesystem.
>All there no hacking required. :)
> 
>
Well JFFS2 is a wonderful filesystem, but it does have it's
detractions.

The main problem with it is the time it spends on mount when
scanning the device; the larger the device, the larger the time.
Also the compression ratio's of CRAMFS are better.

You should use the right tool for the job.

And what's wrong with a little bit of hacking ehh? :-)

Regards

Pantelis

Re: Cram FS on NAND - How to do this?

[Charles Manning]

[snip]
> JFFS2: Read/write, compressed, best support, slow startup.
> YAFFS: Read/write, not compressed, newcomer, fast startup.

YAFFS is being used extensively and has been shipping in commercial products 
for approx 9 months or so with well over ten thousand units in the field.

>
> I have a requirement to have a compressed read only
> root filesystem in my board and I've come to the
> conclussion that the best fit would be CRAMFS if only
> had any concept of bad blocks.
>
> Looking at the code for CRAMFS I see that it would not
> be very difficult to hack it to detect the bad blocks
> and skip over them on startup. We could rely on
> the same OOB info that JFFS2 has, and just
> make a mapping list as follows:
>
> NAND block  bad?  fs block
> ----------  ----  --------
>     0         n      0
>     1         n      1
>     2         y     skip
>     3         n      2
>
> ... etc
>
> The first complication is that CRAMFS works with
> PAGE_SIZE blocks only, and that should be taken
> into account.

That is not a problem. NAND blocks are a multiple of PAGE_SIZE, therefore 
each NAND block holds say 4 cramfs blocks ie. your table becomes
 NAND block  bad?  fs block
> ----------  ----  --------
>     0         n      0..3
>     1         n      4..7
>     2         y     skip
>     3         n      8..11

>
> The second is that this is the first time I hack filesystem
> code and I would like to ask the list if you see any difficulties
> ahead.
>
> What are your thoughts in this?

While some people (myself included)  have suggested some ways you could 
achieve your goals without native cramfs, I really think that native cramfs 
support would be a GoodThing. It is always good to have another option 
(that's why there are over 30 different file systems available for Linux).

I would not be worried about no previous FS experience. This is more of an 
adaptaion of an existing FS. Having a read-only FS makes it much simpler.

Suggestion: GO FOR IT!

-- CHarles

Re: Cram FS on NAND - How to do this?

[Jasmine Strong]

On Fri, 13 Jun 2003, Charles Manning wrote:

> YAFFS is being used extensively and has been shipping in commercial products 
> for approx 9 months or so with well over ten thousand units in the field.

It's gone into products that shall remain nameless which will be or are
shipping in hundreds of thousands;  it works very well indeed.

-J.

Re: Cram FS on NAND - How to do this?

[Brian J. Fox]

   From: Jasmine Strong <jasmine@regolith.co.uk>

   [YAFFS has] gone into products that shall remain nameless which
   will be or are shipping in hundreds of thousands; it works very
   well indeed.

Why does the product have to remain nameless?

Brian
--------------------------------------------------------------------
Brian J. Fox                Roaming Messenger, Inc. 
CTO                         www.RoamingMessenger.com
bfox@RoamingMessenger.com   P:(805) 683-ROAM x119   F:(805) 964-6968
-------------------------------------------------------------------- 

Re: Cram FS on NAND - How to do this?

[Jasmine Strong]

On Fri, 13 Jun 2003, Brian J. Fox wrote:

> Why does the product have to remain nameless?

Because it's covered by a non-disclosure agreement until it is launched.

-Jas.

Re: Cram FS on NAND - How to do this?

[Brian J. Fox]

   Date: Fri, 13 Jun 2003 17:33:07 +0100 (BST)
   From: Jasmine Strong <jasmine@regolith.co.uk>
   Cc: manningc2@actrix.gen.nz, panto@intracom.gr, linux-mtd@lists.infradead.org

   On Fri, 13 Jun 2003, Brian J. Fox wrote:

   > Why does the product have to remain nameless?

   Because it's covered by a non-disclosure agreement until it is launched.

Okay.  Please keep us posted -- this kind of adoption in the consumer
market is exactly the thing that is needed (for many reasons), and I'm
excited to hear about it.

Brian
--------------------------------------------------------------------
Brian J. Fox                Roaming Messenger, Inc. 
CTO                         www.RoamingMessenger.com
bfox@RoamingMessenger.com   P:(805) 683-ROAM x119   F:(805) 964-6968
--------------------------------------------------------------------