Standard FAT file system implementations have a number of weaknesses which mean that if the system is reset unexpectedly then the file system may suffer corruption. To give a few examples:
1. when a file is modified its directory entry containing its length field is in a different location to the data being written – one operation must be done first (for performance reasons this is normally the data) and so if power is lost then the file length field will not be consistent with amount of data and the number of clusters in the files’ cluster chain.
2. a directory entry may span a sector boundary (with long filenames) and so if one sector is written and the other is not then an inconsistency can arise and some of the directory entries cannot be used anymore.
3. when you seek into a file and modify data the normal FAT process overwrites the existing data – so if the system resets then parts of the file maybe modified before a new consistent image has been built. Additionally there is no way to return to the original data.
4. If a directory entry (can be either file or directory) is deleted then either the attached chain must be removed first or the entry itself must be removed first. With an unexpected reset in the first case there may be a directory entry pointing to a cluster chain which does not exist, or in the second case there may be a cluster chain with no reference to it resulting in lost clusters.
5. Deleting a cluster chain is problematical since there are no backward pointers on a cluster chain. There are two options – you can delete from the beginning to the end – in which case unexpected power loss will result in lost chains or you can delete from the end which is very inefficient on large files because there are no back pointers. Again lost cluster chains may result.
There are many more issues with conventional FAT implementations – this is to give a flavor of the issues involved. The current answer to this is checkdisk or another special utility to run – which can correct some of these problems with user intervention – but it is not certain (can never be sure which the last byte written to a file was for instance – or restore overwritten data) – and is also not normally a practical option for an embedded system.
All HCC's SafeFLASH file systems handle these situations cleanly and efficiently.
This text is our view of the situation and should be used for guidance only. In all cases you should contact your lawyers to understand the issues. We are sorry - we did not design the system.
In both the FAT and THIN products we have a definition which allows the developer to enable the use of long filenames. If this is enabled, according to Microsoft, you are required to buy a license from them to use the long filenames. As we understand it there is an initial charge for the right to their technology plus a per unit royalty (0.25c in volume?) to a maximum of 250K USD.
HCC have discussed this issue with Microsoft and, on request, can supply our customers with the necessary legal contact in Microsoft to follow this through.
Benchmarking
HCC tests all its file systems to very high standards and maintains its own set of benchmarks to ensure that its products meet the highest performance possible. However, we do not publish our benchmarks for a number of reasons:
1. We have reviewed numbers published by other vendors and they vary very much in their quality and meaning. It makes no sense to publish numbers which will be compared in unrealistic ways.
2. Benchmarks can be very deceptive - we have produced some wonderful results for some systems - which on paper look fantastic - but are absolutely useless for practical applications. For instance if you use 100% of some resource in a benchark - but have not got a real input source for your data - then when the customer comes to compare it they will see a surprising fall off in performance because they have disturbed the smooth flow of the benchmark design. It is important to design for real aplications rather than to get good benchmark results!
3. Additionally in an embedded design there are a large number of design factors that influence real performance - for example when connecting an SD card to a FAT file system you would have to consider at least the following list: ROM available, RAM available, SPI interface speed (assuming no SD controller), SPI interface type (DMA possible, depth of FIFO etc.), CPU type, CPU speed, cache, SD card type (big variation in behaviour), amount of data being read/written and frequency of those accesses, and more....
We like to discuss real projects with customers and use our understanding, extensive experience and test results to assess whether the target requirements are achievable or not; and to make design recomendations where appropriate.