Detailed explanation of FATFS file system: About SD card, SD nand, spi nor flash and many other flashes

Latest update time：2023-09-20

Reads：

Click on the blue " Linux " in the upper left corner and select " Set as Star "

Read useful articles for the first time

☞ [Dry information] Embedded driver engineer learning route

☞ [Dry information] A comprehensive project based on Linux IoT that can be written on your resume

☞ [Dry information] Linux embedded knowledge points-mind map-free access

☞ [Thank you] My new book "Learning ARM from Scratch" is officially launched

1 Introduction

In the early days of computer development, the size of hard drives and the capacity of flash devices were relatively small. With the continuous iterative updates of technology, the capacity of hard drives is getting larger and larger. In the early days, when faced with small-capacity hard drives/flash, the scheme of storing corresponding data at corresponding addresses was often adopted. Since the amount of data was not large, the operation was okay. But today, as the hard disk/flash capacity continues to increase, more and more data is stored. The early solution of storing corresponding data at a single corresponding address can no longer meet our needs, and operating the hard disk/flash will become abnormal. The difficulties are complex.

Therefore, in response to the above problems, a group of big guys began to design a file system, which is used to manage data information on the hard disk/flash. Like opening a folder on our computer and accessing the files inside, this is actually accessing the computer based on the file system. An operation on data on the hard disk.

Since its development, there have been many versions of the file system. This article mainly shares the detailed design of the FAT file system. The FAT file system is suitable for embedded devices, such as SD cards, SD nand, spi nor flash and many other storage devices. It is also based on this file system. The files can also be read normally by the computer.

2. Basic concepts

Before studying the file system, we need to first clarify several basic concepts about memory:

2.1. Distinguish the concepts of sectors, blocks and clusters

Sector: The smallest unit that flash can operate, usually refers to the smallest unit size we erase, taking SD NAND as an example, usually the minimum is 512Byte
Block (block) and cluster (cluster): In fact, these are two same concepts, but due to historical reasons, they are called different names on different systems. In Windows, they are called clusters, while in Linux, they are called blocks. A cluster/block consists of multiple sectors. Since the space of a sector is small, the file system forms a cluster by combining multiple sectors together, and performs read and write operations in cluster units! A cluster can usually be composed of 2, 4, 8, ..., 2 to the nth power sectors.

2.2. The FAT file system consists of three versions: FAT12, FAT16 and FAT32. This is due to the continuous development of storage technology and the iteration of the FAT file system. The larger the number, the newer the version. The new version is fully compatible with the old version!

3. Introduction to the composition of the FAT file system

Fat file system official documentation:

The layout of the FAT file system on flash is shown in the figure below, which consists of four areas:

reserved area
FAT area
Root directory area (FAT32 type does not include this area)
data area

Next, we analyze an SD card formatted as FAT and understand the implementation details of the FAT file system:

4. FAT file system analysis

4.1 Format SD nand/sd card in FAT format

1. Use win10 to format a 118.5M SD nand / sd card. What I use here is a Genesis CS sd nand plus an adapter board. It is completely no different from the SD card, and the SD nand It has advantages over SD cards in terms of stability.

Due to the size of the SD nand (SD card) here, it is formatted with FAT16 by default! Therefore, in the following article, we first use FAT16 for analysis, and then reformat it into FAT32 for analysis. It is easy to understand!

4.2 Boot sector analysis

1. Use the winhex tool to open the corresponding disk. Note that you need to run it with administrator rights.

2. After opening, we can view all the data on the SD card in binary format. First we see the first sector, which is the corresponding boot sector. Note that the boot sector is located in the reserved area!

3. Next we analyze the boot sector according to the official documentation

Note that FAT file system data is in little-endian format!

a) First is the FAT12/16/32 common part, (offset value 0 - 35):

EB 3C 90: BS_JmpBoot, jump instruction
4D 53 44 4F 53 35 2E 30: BS_OEMName, MSDOS 5.0, a name indicating the operating system that created this volume, no other effect
00 02: BPB_BytsPerSec, sector size 512 bytes
04: BPB_SecPerClus, minimum number of sectors per operation, Cluster, 4 (matches the size selected when formatting 2048 = 512 * 4)
06 00: BPB_RsvdSecCnt, the number of sectors in the reserved area, 6 (can be calculated from this, the starting address of the FAT area is 6 * 512 = 0xC00)
02: BPB_NumFATs, the number of FATs, 2 (generally this value is 2, one more is used for redundant backup, to increase the possibility of recovery when the first one is damaged due to system abnormalities, indicating that there are two FATs in the FAT area backup)
00 02: BPB_RootEntCnt, 512. In FAT12/16 systems, this field indicates the number of 32-byte directory entries in the root directory. Pay attention to alignment when setting this value. For maximum compatibility, this value should be set to 512 on FAT16 systems. , this value should be set to 0 on FAT32 systems
00 00: BPB_TotSec16, 16-bit size area describing the total number of FAT volume sectors, 0. When the number of sectors in the FAT12/16 system is ≥ 0x10000 (65536), this field should be set to 0, and the real value is stored in the BPB_TotSec32 field; for the FAT32 system, this value must be 0. (Here, since our total number of sectors = 118.510241024/512 = 242688 > 65536, this field is 0)
F8: BPB_Media media type
ED 00: BPB_FATSz16, 237, the number of sectors occupied by a FAT. This field is only used in FAT12/16 systems; in FAT32 systems, this field must be 0, and the BPB_FATSz32 field is used instead. The total size of the FAT area is equal to BPB_FATSz?? * BPB_NumFATs sectors (2372512=242688=0x3B400, from which the starting address of the root directory area can be calculated: 0x3B400+0xC00=0x3C000).
3F 00: BPB_SecPerTrk, the number of sectors per track, this field is only relevant for media with geometry and only for the disk BIOS of IBM PC, leave it alone.
FF 00: BPB_NumHeads, the number of heads, this field is only relevant for media with geometry and only for the disk BIOS of IBM PC, don't care.
00 00 00 00: BPB_HiddSec, 0, the number of hidden physical sectors before the FAT volume (when the disk is partitioned, the current partition does not necessarily start from the sector header)
00 B4 03 00: BPB_TotSec32, 242688, 32-bit size area describes the total number of FAT volume sectors (the entire volume space size). In FAT12/16 system, when the total number of sectors is less than 0x10000, this field must be 0, and the real value is stored in BPB_FATSz16; in FAT32 system, this field is always valid. (118.5M = 512 * 242688)

b) Next is the FAT12/16 unique field (offset value 36)

80: BS_DrvNum, the drive number used by the IBM PC's disk BIOS, 00h represents a floppy disk, 80h represents a fixed disk
00: BS_Reserved, reserved field, 0
29: BS_BootSig, extended boot signature, indicating that there are three fields below
83 3E 07 E4: BS_VolID, which together with BS_VolLab constitutes the volume serial number. It is generally generated in combination with the time during formatting.
4E 4F 20 4E 41 4D 45 20 20 20 20: (parsed as: "NO NAME "), BS_VolLab, 11byte volume label, when the volume label does not exist, this value should be set to "NO NAME"
46 41 54 31 36 20 20 20: (parsed as: "FAT16 "), BS_FilSysType file system type, supported fields are: "FAT12 ", "FAT16 " or "FAT ", note that many people think that this field is used to distinguish FAT12/ The 16/32 system type is actually wrong. The file system type is actually determined based on the disk size. It is described in the "Determination of FAT sub-type" chapter of the official document or later in this blog. However, for the sake of maximum compatibility, This field should be set to the name of the corresponding file system.
33 C9 ~ CB D8: BS_BootCode, boot program, related to the platform, filled with 0 when not in use
55 AA: BS_BootSign, 0xAA55, boot signature, indicating that this is a valid boot sector. When the sector size is greater than 512 bytes, the remaining fields should all be filled with 0x0.

c) If it is FAT32, use FAT32 unique field analysis (the offset value is consistent with the FAT12/16 unique field, which is 36)

Although ours here is in FAT16 format, the fields of FAT are also described here for easy understanding.

BPB_FATSz32: The number of sectors occupied by a FAT. This field is only valid in FAT32 systems. The total size of the FAT area is equal to BPB_FATSz?? * BPB_NumFATs sectors.
BPB_ExtFlags: Extended identification field, bit7=0, indicates that all FATs are mirrored and active; bit7=1, indicates that only the FAT indicated by bit3-0 is valid.
BPB_FSVer: FAT32 version, the high byte is the major version number, and the low byte is the minor version number.
BPB_RootClus: The first cluster number of the root directory. This value is usually 2 because the first two clusters are generally reserved.
BPB_FSInfo: The offset sector value between the FSInfo structure sector and the top of the FAT32 volume. This value is usually 1 since it is usually located next to the boot sector.
BPB_BkBootSec: The offset sector value between the backup boot sector and the top of the FAT32 volume. This value is usually 6, for maximum compatibility, other values are not recommended.
BPB_Reserved: reserved
BS_DrvNum: The meaning is the same as the FAT12/16 field
BS_Reserved: The meaning is the same as the FAT12/16 field
BS_BootSig: The meaning is the same as the FAT12/16 field
BS_VolID: The meaning is the same as the FAT12/16 field
BS_VolLab: The meaning is the same as the FAT12/16 field
BS_FilSysType: Always "FAT32", it has no effect on the determination of FAT type.
BS_BootCode32: Boot boot program, dependent on the platform, filled with 0 when not in use
BS_BootSign: 0xAA55, boot signature, indicating that this is a valid boot sector. When the sector size is greater than 512 bytes, the remaining fields should all be filled with 0x0.

The above is a detailed analysis of the contents of the boot sector. Through the contents of the boot sector, we can know important information such as the size of the hardware storage space, cluster size, sector size, and FAT system version that the FAT file system relies on.

At the same time, through the contents of the boot sector, we can calculate important information such as the size and starting offset position of the corresponding four areas of FAT, and then calculate the starting position and size of the four FAT partitions.

4.3 Partition offset and size calculation

The FAT volume is divided into the following four areas:

reserved area

1. The first sector is the boot sector, which stores BPB (BIOS Parameter Block) data and the configuration parameters of the FAT volume.

2. The fields named with BPB_ in the above parameters are all part of BPB, and the fields named with BS_ header are not part of BPB, but only part of the boot sector.

FAT area (partition table loading area)
root directory area
data area

The offset address and size of each partition are as follows:

In addition, regarding the FAT area, there is usually more than one FAT. For example, the SD card formatted here has two FATs. The corresponding offset addresses and sizes are as follows:

4.4 FAT subtype confirmation

Regarding the FAT type, it is confirmed that it is FAT12/16/32: The FAT type is determined by the number of clusters in the data area, there is no other way!

When the number of clusters in a volume is ≤ 4085, it is FAT12
When the number of clusters in a volume is ≥4086 and ≤65525, it is FAT16
When the number of clusters in a volume is ≥ 65526, it is FAT32

The formula for calculating the number of clusters: CountofClusters = DataSectors / BPB_SecPerClus;

As here: CountofClusters = 242176 / 4 = 60544, so FAT16!

When the cluster size ranges from 512 to 32768 bytes under various conditions, the size range of volumes corresponding to different types of FAT is as follows:

4.4 Accessing FAT entries

The FAT area is composed of FAT entries. The specific position of the entries corresponding to FAT[N] is calculated as follows:

FAT16:
FAT32:

It should be noted that different formats have different lengths and formats of corresponding FAT entries:

In addition, for the FAT32 format, the upper 4 bits are reserved bits, and only the lower 28 bits are valid!

The details are shown in the figure below:

4.5 Relationship between files and clusters

So what is the relationship between files and clusters? How do we accurately find the files stored on flash? Next, let's look at the relationship mapping between files and clusters.

Files on a FAT volume are managed through a directory. The directory is a directory entry structure composed of a 32-byte array. This directory structure includes: file name, file size, timestamp, and the first cluster number where the file is located.

Clusters with cluster numbers 0 and 1 are reserved. As can be seen from the parameter BPB_RootClus, the valid clusters start from cluster No. 2. FAT[2] (cluster No. 2) corresponds to the first cluster of the data area.

Therefore, the position calculation formula of the Nth cluster is as follows:

FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus

The location of each entry corresponds to a cluster. When the file length is greater than one cluster length, the value in the entry is the index of the next entry until the last cluster where the file is located, thus forming a cluster chain! The value in the FAT entry corresponding to the last cluster where the file is located consists of a special value (EOC), which will never match any valid cluster number, as follows:

FAT12: 0xFF8 - 0xFFF (typically 0xFFF)
FAT16: 0xFFF8 - 0xFFFF (typically 0xFFFF)
FAT32: 0x0FFFFFF8 - 0x0FFFFFFF (typically 0x0FFFFFFF)

There are some special values used to mark damaged clusters, as follows:

FAT12:0xFF7
FAT16:0xFFF7
FAT32:0xFFFFFFF7

However, it should be noted here that on a FAT12/16 system, the above special value will never match any valid cluster, but it is possible on a FAT32, so to prevent confusion, you should avoid this situation when creating a FAT32 system ! Therefore, the upper limit of clusters on the FAT32 system is 268435445 (greater than 256M clusters)

When the FAT entry is initialized, FAT[2] and subsequent data should be initialized to 0, indicating that it is not used and is in an idle state. If the value is not 0, it means that the cluster is damaged or in use. On FAT12/16 systems, the number of free clusters is not recorded, while on FAT32 systems, FAT32 supports the FSInfo structure, which records the number of free clusters.

About FAT[0] and FAT[1]:

These two reserved entries are not related to any cluster; but have other meanings, as follows:

FAT12: FAT[0] = 0xF??; FAT[1] = 0xFFF;
FAT16: FAT[0] = 0xFF??; FAT[1] = 0xFFFF;
FAT32: FAT[0] = 0xFFFFFF??; FAT[1] = 0xFFFFFFFF;

?? in FAT[0] is the same as BPB_Media;

FAT[1] records the error history: volume dirty flag (FAT16: bit15, FAT32: bit31). The system clears this bit when it starts and restores it when it is shut down normally.

If this bit has been cleared, it indicates that it was not closed normally last time and there may be a logical volume error; the hardware error flag (FAT16: bit14, FAT32: bit30) is cleared when an unrecoverable read and write error occurs, indicating that a comprehensive inspection is required.

There are two important things to note about the FAT area:

The first is that the last sector of the FAT may not be fully used. In most cases, FAT ends in the middle of a sector. FAT drivers should not make any assumptions about unused areas. When a volume is formatted, it should be filled with zeros and should not be changed after that.
Another is that BPB_FATSz16/32 can indicate a larger value than the volume requires. In other words, unused sectors can follow each FAT. This may be caused by data area alignment or other reasons. At the same time, these sectors will also be filled with zeros during formatting.

The following table shows the meaning of FAT values in different FAT types:

4.6 FSInfo sector structure and backup boot sector

This part of the content only exists on FAT32 systems. For FAT12 systems, the maximum size of the FAT area is 6KB. For FAT16 systems, the maximum size of the FAT area is 128KB. However, on FAT32 systems, the FAT area usually reaches several MB. This is because the FAT32 system supports the FSInfo data structure.

The reason for adding the FSInfo data structure on the FAT32 system is that on the FAT12/16 system, if you want to know the number of remaining clusters on the flash, you need to scan the entire FAT area to calculate it. However, as the flash capacity continues to expand, the scanning cost The time is getting longer and longer. In order to avoid wasting too much time on scanning, the FSInfo structure is added to the FAT32 system to record the number of remaining clusters on the flash.

The FSInfo data structure is as follows:

Note: When the sector size is greater than 512 bytes, the remaining space is filled with 0x00

4.7 FAT directory

The FAT directory is divided into a long file name directory (LFN) and a short file name directory (SFN). The long file name directory is an extension of the short file name directory. The specific use of long file name or short file name depends on the FAT file system. Determined by the operating system, such as Windows; when setting a long file name, the short file name is also set for compatibility.

In addition, there is a very important concept: in the FAT file system, a directory is also a file, but the attributes of this file are different.

Among all directories, one special one is the root directory, and the root directory must exist as the top-level directory.

In the FAT12/16 system, the root directory is not a file and is placed in the root directory area. The maximum number of entries in the root directory is indicated by the BPB_RootEntCnt parameter;
In a FAT32 system, there is no difference between the root directory and subdirectories, and the starting cluster of the root directory is indicated by the BPB_RootClus parameter.
Another difference between the root directory and subdirectories is that the root directory does not contain the two dot directories, and it can contain volume labels (entries with the ATTR_VOLUME_ID attribute)

4.7.1 SFN Short File Name Directory

The directory entry structure is as follows:

Regarding the first field DIR_Name of the directory structure, the first element DIR_Name[0] has a special role in the directory table, as follows:

When this value is 0xE5, it means that this directory entry is not used (or has been abandoned)
When this value is 0x00, it also means that this directory entry is not used; in addition, it also prompts that subsequent directory entries are not used, because subsequent directory entries DIR_Name[0] will all be 0x00
If the first character of the file name is the special value 0xE5, use 0x05 instead.

What is the significance of this design? Use DIR_Name[0] as a special character, its directory is to facilitate file deletion! When we delete a file, the file system will not delete all the data corresponding to the file, because that is too time-consuming and unnecessary. Instead, it will directly modify the DIR_Name[0] in the directory entry of the corresponding file. Just 0xE5!

Regarding the file name field DIR_Name, there are also the following provisions in the FAT file system:

The 11-byte file name in the DIR_Name field is divided into two parts: 8-byte main file name + 3-byte extension;
The . in the file name between the main file name and the extension is omitted and is not recorded here.
If the main file name is not long enough and is less than 8 bytes, use 0x20 spaces to pad it.
There are also restrictions on the characters used to set the file name. The supported characters are 0~9 A~Z! # $ % & ' - @ ^ _ ` { } ~
The (a~z) ASCII characters in the main file name and extension will be converted into uppercase characters and saved.

The following is an example of file name storage:

4.7.2 LFN long file name

Long file names are another way to store file names. Since SFN short file names have restrictions on length, characters, etc., they cannot meet the needs in some scenarios. Therefore, long file names need to be used. About long file names The specific contents are as follows:

A long filename is a directory entry with special properties. The value of the long file name directory attribute DIR_Attr field ATTR_LONG_NAME = (ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID) = 0x0F;

Directory attributes for long file names are as follows:

Regarding long file names, there are several important concepts:

A file must have a short file name SFN, but not necessarily a long file name LFN
The long file name LFN field only contains file name information and does not contain other content. Other content needs to be viewed through the short file name SFN.
If a file has both a long file name and a short file name, the long file name is its primary name and the short file name is its additional name.
The long file name LFN entry precedes the corresponding short file name SFN entry.
The long file name of a file can be up to 255 characters long, corresponding to up to 20 long file name LFN entries.
A simple understanding of a long file name is to store a string, so there are no restrictions like SFN. Spaces are allowed, upper and lower case are supported, multiple . symbols are allowed, etc.
The LFN entry file name is not long enough and is still padded with 0x20

The picture below is the official long file name entry on flash for a long file name named "MultiMediaCard System Summary.pdf", as shown below. It doesn't matter if you don't understand it at first glance. There are examples below to illustrate the long file name. Just get the concept!

Regarding the checksum field and calculation of long file names, the algorithm is as follows:

uint8_t create_sum (const DIR* entry)
{
int i;
uint8_t sum;
for (i = sum = 0; i < 11; i++) { /* Calculate sum of DIR_Name field */
sum = (sum >> 1) + (sum << 7) + entry->DIR_Name[i];
}
return sum;
}

4.7.3 Compatibility of LFN system with SFN

In systems that use LFN long file names, SFN short file names are automatically generated to ensure that this file can be used in file systems with short file names. At the same time, in order to prevent conflicts in the generated short file names, the SFN is generated in the format of name + numeric suffix + extension, and the following rules are used to generate SFN:

Automatically convert lowercase to uppercase
If there are spaces, delete the spaces and set the lossy conversion flag.
For files that begin with ., delete the . in the header and set the lossy conversion flag.
There are multiple . file names, only the last one is retained as the separation between the file name and the extension, and the lossy conversion flag is set
For other unsupported characters, use _ instead and set the lossy conversion flag.
If the file name is in Unicode encoding, it will be converted to ANSI/OEM encoding; characters that cannot be converted are replaced with _, and the lossy conversion flag is set.
Parts longer than 8 bytes are truncated and the lossy conversion flag is set.
If the extension field exceeds 3 bytes, it will be truncated and the lossy conversion flag will be set.

The lossy conversion conversion identifier is: ~, the ASCII value is 0x7E, and the decimal value is 126

Examples are as follows:

At this point, the theoretical part of the FAT file system has been described. Next, we continue to use winhex to analyze the data.

5. Partition analysis

Let’s continue looking back at the layout diagram we had at the beginning

5.1 Reserved partition analysis

The reserved partition is the first partition, where the boot sector is located in the first sector of the reserved partition.

According to the calculation results in Chapter 4.3, it can be seen that the starting address of the reserved partition is 0x00 and the size is 0xC00

The reserved partition data is as follows. The most important content in the reserved partition is the boot sector. Except for the boot sector, all other remaining spaces are reserved and overwritten with 0x00. The boot sector has been analyzed in detail in Chapter 4.2 and will not be introduced here.

5.2 FAT area analysis

According to the description in Chapter 4.3, the starting address of the FAT area is 0xC00 and the size is 0x3B400. In addition, there are two FAT areas, FAT1 and FAT2. The starting addresses are: 0xC00 and 0x1E600 respectively. The corresponding address data is as follows:

FAT1 data:

FAT2 data is as follows:

Since the FAT16 format is used here, each FAT entry takes up two bytes!

Analysis based on the above data:

Confirm that FAT2 is a backup of FAT1;
There are 5 FAT entries, of which FAT[0] and FAT[1] are reserved entries. The content of FAT[0] is consistent with the BPB_Media media type field. FAT[1] is used to record error history (see description in Chapter 4.5 for details)
According to the description in Chapter 4.5, FAT[2] (cluster No. 2) corresponds to the first cluster of the data area, and the data of FAT[2], FAT[3], and FAT[4] are all 0xFF, indicating that there are three files, and The size of each file is less than or equal to the space of one cluster; and they are stored in the first to third clusters of the data area!

You may wonder here why the file was stored in the SD card you just formatted. In fact, this is a system file that comes with it after formatting. It is hidden by default and can only be seen using winhex, which is the corresponding System file. Volume Information folder.

5.3 Root directory area analysis

Note that the root directory area only exists on FAT12/FAT16 systems, this area does not exist on FAT32 systems.

The root directory area is used to record the contents of files in the root directory. According to the calculation in Chapter 4.3, the starting address of the root directory area is: 0x3C000, the size is 0x4000, and the data content is as follows:

The following is the content after analyzing the data fields, as shown in the figure below:

After formatting, a system folder of System Volume Infomation will be generated by default. At the same time, this folder is the only file in the root directory, so the data in the root directory is as shown in the figure above.

This folder is a directory attribute and is a hidden system directory
The long file name is System Volume Information and the short file name is SYSTEM~1
This directory points to the data stored in cluster 2 (corresponding to the first cluster in the data area). The file size field is meaningless because this file is a directory attribute, so it is forced to 0.

At this point, the analysis of the root directory area is completed. At the same time, the System Volume Information file in the root directory area points to the first cluster in the data area (cluster No. 2). Next, we enter the data area for analysis.

5.4 Data area analysis

According to the calculation in Chapter 4.3, the starting address of the data area is: 0x40000, the size is 242176 * 512 = 0x764 0000, and the data content is as follows:

The corresponding data field analysis is as follows:

There are two files in the System Volume Information directory, namely IndexerVolumeGuid and WPSettings.dat. According to the above analysis, it can be seen that:

The data of the IndexerVolumeGuid file is stored in FAT[3], cluster No. 3, which is the third cluster in the data area (the first cluster in the data area is cluster No. 2);
The data of the WPSettings.dat file is stored in FAT[4], cluster No. 4, which is the second cluster in the data area (the first cluster in the data area is cluster No. 2);

First, we jump to cluster 4 to view the IndexerVolumeGuid data. The corresponding address calculation method is:

FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus = 512 + (4 - 2) * 4

= 520;

The corresponding address is: FirstSectorofCluster * BPB_BytsPerSec = 520 * 512 = 0x0004 1000

Then jump to cluster 3 to view the data of WPSettings.dat. The corresponding address calculation method is:

FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus = 512 + (3 - 2) * 4

= 516;

The corresponding address is: FirstSectorofCluster * BPB_BytsPerSec = 520 * 512 = 0x0004 0800

5.5 New file test

1. Add a test directory under the root directory, use winhex to update disk data, and observe changes in each data area.

No changes to the reserved area
The changes in the FAT area are as follows:

The root directory area changes as follows:

Data area changes:

2. Add a new long file test folder, store a test.txt file with a length of 2050 Byte (occupying the space of two clusters), and use winhex to reopen the disk for analysis.

No changes to the reserved area
The changes in the FAT area are as follows:

The root directory area changes as follows:

The changes in the data area are as follows:
long file test directory data points to cluster 6, jumps to cluster 6, address DataStartSector + (N - 2) * BPB_SecPerClus = 0x40000 + (6-2) * 4 * 512 = 0x420000

The test.txt file points to cluster No. 7 and jumps to cluster No. 7. The address DataStartSector + (N - 2) * BPB_SecPerClus = 0x40000 + (7-2) * 4 * 512 = 0x428000 is the actual valid data of test.txt. ,as follows:

6. Summary

The above is the complete analysis of the FAT file system. Through the above analysis, plus the auxiliary understanding of new files, I believe that we have a very in-depth understanding of how files are managed and stored under the FAT file system.

The FAT file system is divided into four areas:

The most important thing about the reserved area is that it contains the boot sector. The boot sector stores BIOS parameter information. Through this parameter, you can know the flash layout of the FAT file system, as well as key information such as flash size, fat block size, and cluster size;

The FAT area records the clusters occupied by the file, and for files larger than one cluster, a cluster chain is formed in the FAT area to record which clusters the file is composed of.

The root directory area is only owned by FAT12/16 systems and records the file/directory entry information under the root directory.

In the data area, the recorded data is divided into two parts. The first part is directory information. Except for the root directory, each folder needs to occupy one or more clusters to describe the files in the corresponding directory; the second part is specific file data. The two parts of data are related through the short file name SFN field!

The above is a simple summary of the FAT file system, since this article uses the FAT16 file system as an example analysis.

end