I have serious problems with the stability of the FAT filesystem ...
We have developed a NETMF-application, which acquires and stores data to the FAT filesystem (on a NAND flash).
The device/application is intended to run stand-alone, i.e. without a permanent network connection, so the reliability of the filesystem is very important for our needs.
Unfortunately I had to realize that the filesystem doesn't seem to be very stable.
I found that occasionally some files and/or the filesystem became corrupted. In that case blocks of data (most times multiples of 512 bytes) within a file were filled with 0xFF. Sometimes also the directory structure seems to be affected.
The problems first encountered with the framework version 4.0. In the meantime, I have started a lot of tests based on version 4.2, which also leads to problems. My application uses multi threading and does many other things besides writing files.
To isolate the potential causes for these file corruptions, I have implemented a simple test application, which only writes files and compares them afterwards. To be more exact, the test proceeds as following:
- Format the root volume
Until there is no more free space ...
- write defined content to a FileStream (within a 'using' statement)
- open file again, read content and compare
After the filesystem is full, start a second compare run over all files.
Many tests lead to different failures, but the failures are not reproducible in that way, that always the n-th file after formatting is affected.
sometimes the file creation or writing itself leads to an exception, e.g. ...
Exception System.IO.IOException - CLR_E_FILE_IO (1)
Microsoft.SPOT.IO.NativeFileStream::Write [IP: 0000]
System.IO.FileStream::Write [IP: 002a]
sometimes the direct compare after writing detects failures (larger blocks filled with 0xFF)
when there were failures, the second compare run sometimes detects more failures than stated before. So it seems, that files which were written correctly are corrupted afterwards.
alter reboot (after failure) the FAT sometimes states to be not formatted
in rare cases, the test completely hangs up.
I just had the situation, that I was not able to format the volume. After erasing the filesystem region via MFDeploy, it works again.
Now for my questions ...
Are these problems based on any known bugs?
Is there any way to avoid or reduce these problems?
(Is there something to consider concerning filesize, max amount of files, formatting, FileStream usage, threading, ... )
I would appreciate ANY hint ...