OpenQNX :: The QNX Community Portal

Hi,

On my workstation I started devf-ram driver with the following parameters:
# devf-ram -s0,8M,,,64k,2,1 &

After format (with 1024k limit)

# flashctl -p /dev/fs0p0 -l1M -e -f -n /flash -m -v
...

the 'df' utility reports that my partition has 960k (1024k -64k).

Where this "one block" difference come from ?
Is this block required for flash file system internal usage ?

Regards,
Jacek

Yes that's the space block, for moving stuff around. That the price to pay
for having a ram disk build on top of a flash file system architecture. I
don't think you can set it to 0

Yes that's the space block, for moving stuff around. That the price to pay
for having a ram disk build on top of a flash file system architecture. I
don't think you can set it to 0

This block is missing even on the real target running custom devf-* flash
driver.
Where can I find some more information about that ?

Jacek

Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
Yes that's the space block, for moving stuff around. That the price to
pay
for having a ram disk build on top of a flash file system architecture.
I
don't think you can set it to 0

This block is missing even on the real target running custom devf-* flash
driver.
Where can I find some more information about that ?

Jacek

NOR flash, when erased, has all bits set to 1. A bit can transition from 1
to 0,
but the only way that a bit can transition from 0 back to 1 is to erase an
entire
block of flash. The block size is defined by the flash specification for a
particular
part, typically 64k or 128k. Interleaving flash will also increase the
block size. For
example, two 8 bit flash parts, each with a 64k block size, and
interleaved together,
will have a 16 bit bus width, and a 128k erase block size.

Because flash bits can only transition from 1 to 0 under normal
circumstances, once
a file is written to a particular area of flash, it cannot be changed or
overwritten.
For that to happen, it must be moved to a different area of the flash,
which has not
yet had any of its 1's changed to 0's. As a result, the filesystem must
keep at least
one block 'spare', so that when the filesystem fills up, and 'stale' areas
of the flash
need to be reclaimed, the valid files can be copied out of the partially
used blocks,
and into the erase block. Then, the invalid blocks can be erased, space is
reclaimed,
and some other block now becomes the erase block. This is all taken care
of by the
flash filesystem, without the user needing to worry about it. Reclaim
operations can
also be forced with the -r option to flashctl.

It is possible to specify that a flash filesystem will have no erase block
(making it
read-only). You can use the -s 0 option to flashctl, or if you're using
mkefs to
generate your flash filesystem, you can specify spare_blocks=0 in the efs
build file.


--

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com