I'm using FatFS for a filing system on a nor flash device (e.g. RT1020-EVK) and I have a some questions:
I had a quick look at the source and it looks like files can be fragmented, because the file object sets up a fragment chain, or something like that. In fact that seems to be the way FAT works - linked lists of clusters.
I just want to ask if my understanding is correct:
a. Files can be fragmented without any problems.
b. No defragmentation is required to fit large files in, because it is all sector based and there is a chain for each file maintaining which sectors are occupied by it. So the file does not need to be contiguous etc.
2. Erasing Sectors:
At the moment when FatFS asks me to write a sector, I always erase it first (just to get things working). However if the sector has already been erased, this seems unnecessary. Does FatFS provide a way to handle this? Or do I need to maintain a map (of sectors that need erasing) or something and handle this myself?
Thanks and kind regards,
1. There are some practical examples of the low level details of file objects and clusters in chapter 7 of https://www.utasker.com/docs/uTasker/uTasker_utFAT.PDF (valid for all FAT implementations) whereby file content occupies clusters which can be located anywhere and in any order in the cluster area.
De-fragmentation is only needed on magnetic disk drives where (the physical head) jumping around takes time - on SD cards or in NOR flash de-fragmentation has no benefits.
2. What size are your physical NOR flash sectors and the FAT sectors? Usually the FAT sector size is 512 bytes and smaller than the physical erase sector size. This means that erasing physical sectors on each write usually erases multiple sectors and requires the valid sectors to be written back again too (unless only one FAT sector size is saved in a physical sector). Often (maybe usually) a wear-level layer is inserted to allow FAT sectors to be mapped to physical NOR flash so that (as long as there are still blank sector space) writes can be made anywhere that is already free without needing to first erase and copy back data along with the new sector to be written. Dirty sectors can then be cleaned up as a background task (which does involve a form of de-fragmentation invisible to the FAT) and valid content be moved around if needed to ensure that the write/erase cycles are shared evenly across the NOR flash so that there are not sectors that are used intensively (with potential to wear out) while others are rarely used.
There is a description of a wear leveling method that I use for NAND flash here: https://www.utasker.com/docs/uTasker/uTasker_NAND.pdf whereby NAND and NOR flash are different mainly in the fact that NAND flash is inherently unreliable and blocks do fail (when their error correction cannot correct any more bad bits) and need to be managed in an additional bad block table.
[uTasker project developer for Kinetis and i.MX RT]
[Developer of utFAT]