Re: Text File Open for Writing and Viewing.

"Steve McKewen" <steve.mckewen@xxxxxxxxxxxxxx> wrote:

>>
>> This is bad for most Flash File Systems! A lot of traffic but also an
>> impact to the life cycle of the Flash Memory Chips.
>>
>Are you sure this is bad for the FFS. Openning and Closing the file doesn't
>actually write to the FFS does it? The file control data is in RAM, so the
>open and close only changes RAM contents. Writing to the log file, either
>in small blocks or large blocks, still writes the same data to the same
>places.

Oh no!

1st,
there is a significant difference between NAND-Flash, which could only
be written in complete blocks and NOR Flash, which is acessible like
RAM.
Okay, NAND can be rewritten 2 to 3 times in sigle byte acess, only
after this ist must be deleted before next write operation. Often,
developers ignore that and make a delete on EVERY write access.
Hugh disks are in most cases NAND, since NAND needs only 40% of the
size a NOR flash would need on the Die. So you should at least check,
if your device has NAND or NOR Flash ... and if your program in the
future could run on NAND.

2nd,
> Writing to the log file, either in small blocks or large blocks,
> still writes the same data to the same places.
You are right, if you only talk about the data. But are you shure, the
file control data (FAT or MFT) is _really_ in RAM only?
I know only one CE manufacturer who bufferes the FAT in RAM
(www.skeye.com, which is a company of hoeft & wessel). As I heard,
nearly all other WinCE 4.2 manufacturer use the M$ default FAT code,
which writes every change to the FAT directly trough into the flash
chips.
If this is right, the FAT area would receive heavy traffic. Regardless
of NAND/NOR - the chip would have reduced life.

AFAIK the following happens with an partially filled sector on next
data append:
- the File System Driver searches an unused block
- [optionally] File System Driver checks, if the Block can be
rewritten without erasing
- erasing of this new block
- copies the old, partially filles data segment to that block
- appends the new data onto this block
- changes the FAT/MFT (may be in RAM, see above) to point to the new
block + represent the new size
- marks the old block as unused.

NOW THE WORST THING:
M$ still uses 512 Byte/cluster in its FAT architecture while almost
all NAND Flash chips use at least 4k Pages. So, if we change ONE Fat
sector, in wost case we have to reorganize 4k of the Flash. In best
case, when we only write in complete modulo 4096 parts, we will still
have 4 single accesses to the Flash page. With worse code, this could
result in 4 times moving the data into a new free sector.

NOW THE GOOD THING:
You can find it out. Use your biggest disk you have. Make it clean &
empty as far as possible. more than 64 MB would be best. (We
encountered best visible values with 1GB)
Write a program, which incrementally grows a file in (selectable) fix
sizes. 4096 Bytes would be a good start. Then count the number of
write accesses every, say, 1/10 second. Make a graphic where y is the
count and x or t is time. As you remember, "y=f(x)=n*x+m" or,
"y=f(t)=n*t+const" If you get nearly "y=const" (tiny 'n'), you should
have RAM buffering. If you get a significant 'n' or if you get some
y=f(x)=mx²+nx+q or y=e^(x) type graphic, you have for shure no RAM
controlled FAT.

Repeat the test with:
4096 bytes, but file has still 392 Bytes (so it grows to 4488, 5000,
....)
512 bytes, file starts with 0 bytes
512 bytes, file starts with 392 bytes

and compare the graphics. Remember, the bigger the free space, the
better the results. The graphics could say a lot of the impact of the
start values onto the speed. This could be used to guess what part of
the file system is buffered and what not.


BTW:
On my tests, on some devices the result seemed to also depend on the
usage of the write method: CreateFile/WriteFile/CloseHandle or
fopen/fwrite/fclose (C-Runtime Library).

"fwrite" always use 512 byte buffering (fsetbuff is not provided by
M$), while WriteFile speed seems to be manufacturer depending. But
IIRC, one can change the default behavior of WriteFile by some not
often used flags in CreateFile.

Let me know, what you found out...

Mai Kee

--
Hamster beisst sich durch ...
.

Relevant Pages

  • RE: Flash Memory Wearing Qeustions
    ... File System) like JFFS or TrueFFS because unlike FAT, ... Samsung NAND flash memory. ... - FAT file systems writes the file's Directory Entry Structure each ...
    (microsoft.public.windowsce.embedded)
  • Re: Flash driver for wince 5.0
    ... I am going to design flash driver of 128MB size for a handset. ... Whether I have to use HIVE BASED REGISTRY or RAM based registry? ... My second doubt is selecting the internal file system. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Flash filesystem
    ... how can i specify the location of the two fat table used in TFAT? ... in some flash, the earse block is too big that a single erase will kill both ... > is not much a file system can do to make things safe. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Sync option destroys flash!
    ... > Given sync doesn't appear to be the default, ... >> block or two of the flash drive. ... don't all buy our flash drives at an industrial supply house (forget ... > yes that would destroy the sectors holding the FAT. ...
    (Linux-Kernel)
  • Re: Flash Media Driver
    ... that some blocks are getting marked read-only in your FAT partition. ... is your image XIP directly from flash or are you using BINFS? ... > For the file system, I am specifying the FAT file system. ... > Moreover, without specifiying the FAT filesystem in the registry, my Flash ...
    (microsoft.public.windowsce.embedded)
Loading