Re: JFFS2 - flash lifetime estimate - Embedded

This is a discussion on Re: JFFS2 - flash lifetime estimate - Embedded ; gcartabia wrote: > I'm using a JFFS2 filesystem on a NOR flash. > > these are the features of my system: > - the flash size is 32MB with 256 erase blocks; > - block size is 128KB; > - ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: JFFS2 - flash lifetime estimate

  1. Re: JFFS2 - flash lifetime estimate


    gcartabia wrote:

    > I'm using a JFFS2 filesystem on a NOR flash.
    >
    > these are the features of my system:
    > - the flash size is 32MB with 256 erase blocks;
    > - block size is 128KB;
    > - erase per blocks are 100,000;
    > - most files on filesystem are static;
    > - there is only one dynamic file;
    > - this file is fixed size (about 512KB);
    > - the file is binary and record based;
    > - every record in the file is 44 byte;
    >
    > A single operation on the file writes a record sequentially. When it
    > reaches the end of the file restarts to write from the first record.
    >
    > If I have 10,000 operations per day, how can I estimate the lifetime of
    > my system?


    A quick and dirty way is to add a counter in the block erase routine,
    and see how many records you can write for each block erase. You could
    even maintain a histogram and see how well the wear levelling is
    implemented.


  2. Re: JFFS2 - flash lifetime estimate


    gcartabia wrote:

    > > A quick and dirty way is to add a counter in the block erase routine,
    > > and see how many records you can write for each block erase. You could
    > > even maintain a histogram and see how well the wear levelling is
    > > implemented.

    >
    >
    > yes, this could be ok, I have a on-chip debugger and I can trap it. But
    > I don't know the name of the erase routine.


    Looks like jffs2_erase_block in fs/jffs2/erase.c would do.

    Instead of trapping it in the debugger, I would just put a printk() in
    there, and let it run for a while (possibly at increased speed), and
    capture the kernel log.


+ Reply to Thread