[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS size problem



If you read the FAQ in the HOWTO doc, you will come accross the
following:

Q. What is this "interleave" stuff?
<snip>

If you are designing your own hardware, if possible use the maximum
width of the processor data bus as you will be able to write out 4
times faster per word write to your flash, x32 compared to a x8
connection.

But you need to be aware of a tradeoff with this approach. All flash
chips used to fill the processor buss will have their sectors erased at
the same time. In other words, 4 x8 chips interleved by 4 on a 32 bit
bus, with 64KB even sectors will have an erase size of
4*64KB=256KBytes. Why should you care about this? Because, the JFFS
code needs to keep a minimum number of sectors free to continue to
garbage collect. At this time, that minimum number is 2 sectors. In
other words, in the above example, you will never be able to put data
in 512KBytes of your jffs flash device. You may care about this. If
you do, and write speeds are not that important to you, then connect
your x8 bit flash devices to an x8 bit processor bus (or as a byte
wide memory on your 32 bit data bus). Then you will have an erase size
of 2*64KB = 128KBytes.

(Actually I lied a bit in above, as I found out looking at the code, see
below)


        fmc->used_size = 0;
        fmc->dirty_size = 0;
        fmc->free_size = mtd->size;
        fmc->sector_size = mtd->erasesize;
        fmc->max_chunk_size = fmc->sector_size >> 1;
        /* min_free_size:
           1 sector, obviously.
           + 1 x max_chunk_size, for when a nodes overlaps the end of a
sector
           + 1 x max_chunk_size again, which ought to be enough to handle

                   the case where a rename causes a name to grow, and GC
has
                   to write out larger nodes than the ones it's
obsoleting.
                   We should fix it so it doesn't have to write the name
                   _every_ time. Later.
           + another 2 sectors because people keep getting GC stuck and
                   we don't know why. This scares me - I want formal
proof
                   of correctness of whatever number we put here. dwmw2.
        */
        fmc->min_free_size = fmc->sector_size << 2;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

sector_size is 256K. Min space stashed away for GC is sector_size * 4!
In your case = 256K*4 =1Meg!

Hence, my trade off comment in the FAQ above is even more relevant!

Vipin


Axel Barnitzke wrote:

> On my ipaq /dev/mtd shows:
>
> mtd6: 00300000 00040000 "BITSY usr local"
>
> when I make a fresh jffs filesystem on /dev/mdt6
> (eraseall /dev/mtd6; mount -t jffs /dev/mtdblock6 /usr/local)
> df -k shows:
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/mtdblock6            2048         0      2048   0% /usr/local
>
> When I compute right -- I lost 1Meg
> any clues?
>
>   -- Barney
>
> --------------------------------------
> ++ axel (barney) barnitzke
> ++ it consultant
> ++ lisa systems
>
> email :: mailto:barney@xxxxxxx.de
>
> To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
> the body of a message to majordomo@xxxxxxx.com


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com