Block Alignment on SD Cards
While I was playing around with connecting SD cards to the ESP8266, I ran the SdInfo sketch and found one interesting message.
I find this intriguing since as a computer user, I’ve always seen SD card as a raw storage device where it stores bytes and you can put any kind of data and any kind of file system on it. This is a compliment to the abstraction layer that works so well that I have never bothered to look under the hood as to how SD cards work.
After more research, I’ve found out that the SD Card Association actually specifies the standard file system to use with SD card, and it’s not just “use FAT32” but actually specifies how the file system should be aligned on the card.
It appears that, starting from SDHC, you can only write to the SD card in sectors of 512 bytes, so you cannot just write one byte, you have to tell the SD card the entire sector (512 bytes) you want to replace the content with. If you want to write just one byte, you have to read the 512 bytes, change one byte in memory, then write back the entire 512 bytes.
FAT32 file system also have cluster size. This means that each 4 KB sector on the disk is assigned to only one file (of course, a file can span multiple sectors) so as long as you write only to that sector, you do not have to worry about accidentally overwriting other files. According to Microsoft, for most partition sizes, the cluster size is 4 KB, which fits exactly into 8 SD card sectors.
So when writing a cluster, you can just directly issue write commands to 8 sectors.
Now what happens when you create a partition without being aware of the idiosyncrasy of the underlying storage. Most likely the cluster on the file system does not match the sector on the SD card. This results in the cluster spanning 9 sectors instead of 8.
In the above example, you would need to issue a read command to sector 8000 and 8008 in order to partially overwrite them (you need to preserve the first part of sector 8000 and the last part of sector 8008 since have data from different clusters). So in the end, you need to read 2 sectors and write 9 sectors, which is less efficient.
In the grand scheme of things, computers have a lot of memory to be used to caching these data and files generally span multiple continuous clusters, so the problem is less severe. If you need to write one cluster, it’s 11 commands instead of 8 (37% more commands). But if you need to write 1000 continuous clusters (e.g. a 4 MB file), it’s 8003 commands instead of 8000 (0.037% more commands), so the problem is not that serious.
However, if you’re on a micro-controller with limited memory and code storage space, then this becomes more of an issue. Not only will you need additional memory to cache data for writing, but your code will be more complex as it needs to handle the case.
If it’s specified that the FAT32 file system on SD cards must have clusters aligning to the sectors of SD cards, your code can simply ignore this edge case and refuse to work with improperly formatted SD cards. Thus, I can see why the SD Card Association wants to specify the file system up until this level.
