Re: flash file system for production use

Re: flash file system for production use

[Michael Palme]

[forget CC to the list...]

> hello...
>
> there are 7 mtd partitions on the 32Mb NOR flash right now. (256k
> bootloader, 256k kernel parameters, 1M kernel1, 4M ramdisk1, 1M kernel2,
> 4M ramdisk2 and the rest (21.5M) goes to 1 jffs2 data partition. i want
> no flash- rootfs because of performance issues -- i think a ramdisk is
> always the fastest.
>
> the reason behind the _very_big_ jffs2 partition is that i want to
> assure that the flash will never(?) fail because of weak blocks sometimes.
>
> but thats also my fear -- i think the bigger the jffs partition the
> slower it gets after some time of use because of the effort of the wear
> leveling??? is this right???

I think it gets slower due to fragmentation. A JFFSx file system must scan at 
start up. A big fagmented partition will scan slower. I don't know enough 
about JFFSx, my main knowledge is about YAFFS which works on NAND.

>
> so what i want to know is: is a smaller jffs2 partiton better from the
> performance view??? i will have no complex tree structure on the
> partition, only 2 directorys with some small files...
>
> cheers Michael Palme
>
> Charles Manning schrieb:
> >Have you considered partitioning?
> >
> >One partition for config files etc (stuff you need ASAP on boot).
> >Another for verbose guff that you can mount at leasure.
> >
> >-- Charles
> >
> >On Wed, 28 Aug 2002 07:03, you wrote:
> >>hello...
> >>
> >>i've got a strongarm system with 32mb intel strata flash. i need a
> >>mechanism for storing configuration files etc in the flashes. for this
> >>purpose 20mb of the flashes are free. the performance/ stability thing
> >>is very important for me. i cant wait 10 secs fot mounting/ checking
> >>etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly
> >>empty flash partition, but i have no suggestion about what happens in
> >>hard production use, when the flash will be written  over and over again
> >>and the wear leveling takes place. the device is never shutdown'ed in a
> >>clean way -- always hard power off...
> >>
> >>because i have 20megs free and only small information to store i think
> >>there is no need for a complex wear leveling mechanism but im not an
> >>expert.
> >>
> >>what the best solution fot my problems???
> >>
> >>please give some hints....
> >>
> >>
> >>thanks in advance ... Michael Palme

flash file system for production use

[Michael Palme]

hello...

i've got a strongarm system with 32mb intel strata flash. i need a 
mechanism for storing configuration files etc in the flashes. for this 
purpose 20mb of the flashes are free. the performance/ stability thing 
is very important for me. i cant wait 10 secs fot mounting/ checking 
etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly 
empty flash partition, but i have no suggestion about what happens in 
hard production use, when the flash will be written  over and over again 
and the wear leveling takes place. the device is never shutdown'ed in a 
clean way -- always hard power off...

because i have 20megs free and only small information to store i think 
there is no need for a complex wear leveling mechanism but im not an expert.

what the best solution fot my problems???

please give some hints....


thanks in advance ... Michael Palme

-- 
-------------------------------
Dipl.-Ing. (FH)
Michael Palme
software engineer
Goepel electronic GmbH

mailto: m.palme@goepel.com
phone:  +493641689682
fax:    +493641689644
inet:   http://www.goepel.com
-------------------------------

Re: flash file system for production use

[David Woodhouse]

m.palme@goepel.com said:
>  i need a  mechanism for storing configuration files etc in the
> flashes. for this  purpose 20mb of the flashes are free. the
> performance/ stability thing  is very important for me. i cant wait 10
> secs fot mounting/ checking  etc. i' ve tried jffs2 from CVS and it
> seems to be "fast" on a nearly  empty flash partition, but i have no
> suggestion about what happens in  hard production use, when the flash
> will be written  over and over again  and the wear leveling takes
> place. the device is never shutdown'ed in a  clean way -- always hard
> power off... 

JFFS2 from CVS should be fine. It hasn't had as much hard testing as the
stable branch, but I have no particular reason to expect it to be broken on
NOR flash. I wouldn't ship it to a customer before doing some serious
retesting, but you can do that yourself and report anything you find -- I
don't expect anything to break.

There are other things we can do to improve performance and mount time even
more than we've already done in CVS. They're listed in the TODO file, and if
you're likely to actually implement them I'm happy to give more explicit
pointers -- or I can set our salesdroids on you if that would be useful :)

--
dwmw2

Re: flash file system for production use

[Michael Palme]

okay... thanks for the answer.
i will do some serious testing myself. what would be a real life 
scenario ??? is a random loop with creating, writing and deleting files 
mixed with mounting and unmounting and some random powerfaults???

i think the salesdroids- thing will not work: they only thing they want 
is to get a product to the market as fast as they can...

David Woodhouse schrieb:

>m.palme@goepel.com said:
>  
>
>> i need a  mechanism for storing configuration files etc in the
>>flashes. for this  purpose 20mb of the flashes are free. the
>>performance/ stability thing  is very important for me. i cant wait 10
>>secs fot mounting/ checking  etc. i' ve tried jffs2 from CVS and it
>>seems to be "fast" on a nearly  empty flash partition, but i have no
>>suggestion about what happens in  hard production use, when the flash
>>will be written  over and over again  and the wear leveling takes
>>place. the device is never shutdown'ed in a  clean way -- always hard
>>power off... 
>>    
>>
>
>JFFS2 from CVS should be fine. It hasn't had as much hard testing as the
>stable branch, but I have no particular reason to expect it to be broken on
>NOR flash. I wouldn't ship it to a customer before doing some serious
>retesting, but you can do that yourself and report anything you find -- I
>don't expect anything to break.
>
>There are other things we can do to improve performance and mount time even
>more than we've already done in CVS. They're listed in the TODO file, and if
>you're likely to actually implement them I'm happy to give more explicit
>pointers -- or I can set our salesdroids on you if that would be useful :)
>
>--
>dwmw2
>
>  
>

Re: flash file system for production use

[David Woodhouse]

m.palme@goepel.com said:
> okay... thanks for the answer. i will do some serious testing myself.
> what would be a real life  scenario ??? is a random loop with
> creating, writing and deleting files  mixed with mounting and
> unmounting and some random powerfaults???

Yeah -- coupled with sanity checking every existing file on the file system 
at every remount, etc. And make them _real_ powerfaults, with an X10 
controller or something. You get really weird behaviour out of flash chips 
that way -- which we should deal with just fine.

If you're going to report any faults, it's best to do the testing with 
CONFIG_JFFS2_FS_DEBUG=1 and _logging_ the kernel messages over a serial 
port. But that of course slows down the test run. YMMV. A 230400 baud 
serial console helps :)

--
dwmw2

Re: flash file system for production use

[Thomas Gleixner]

On Tue, 2002-08-27 at 21:03, Michael Palme wrote:
> hello...
> 
> i've got a strongarm system with 32mb intel strata flash. i need a 
> mechanism for storing configuration files etc in the flashes. for this 
> purpose 20mb of the flashes are free. the performance/ stability thing 
> is very important for me. i cant wait 10 secs fot mounting/ checking 
> etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly 
> empty flash partition, but i have no suggestion about what happens in 
> hard production use, when the flash will be written  over and over again 
> and the wear leveling takes place. the device is never shutdown'ed in a 
> clean way -- always hard power off...
> 
> because i have 20megs free and only small information to store i think 
> there is no need for a complex wear leveling mechanism but im not an expert.
> 
> what the best solution fot my problems???
> 
You have to decide, whats more important stability or preformance. If
you write small but important information and your system has the
possibility of power loss, then you have to use a stable, journalling
flash file system like JFFS2 and accept some performance penalty. The
actual JFFS2 code in CVS is faster than the stable branch. It needs some
serious testing. And there is place for further improvents. You're
heartly intvited to join us and implement some of the things, which are
listed in the TODO file.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de