Having just written a FAT library, I've spent quite a bit of time deeply involved in the layout of that particular file system. 😁
So, about alignment: There are a few data regions on the disk, and there's a strict formula for defining their starting location and length. You CANNOT alter that and still be compatible with FAT drivers. Many of those regions don't even have pointers in the headers anywhere. Their location is known relative to other aspects of the layout.
Here's how it looks on-disk:
Sector 0 is the volume boot record (VBR), or "boot sector" region. This contains the 0x55 0xAA boot signature used by the MBR boot loader to detect a bootable partition, some descriptive fields, and the BIOS Parameter Block (BPB), which defines the characteristics of the underlying disk and the file sytem as originally created upon that disk. (Any space not allocated to the above can be used for stashing additional boot loader code.)
Sector 0 is part of what is known as the "reserved sectors." With FAT12/16, there is usually only the one reserved sector -- #0. With FAT32, there are customarily 32 reserved sectors, including sector 0. However, the BPB includes a field where the number of reserved sectors is defined, so you CAN tweak this. AFAIK, it was originally designed to allow you to carve out additional space for boot loader code, but there's no reason you can't use it to force alignment goals.
FAT32 introduces some new structures -- a backup boot sector in case the original is unreadable, and the "FS Info" structure, which caches the number of available clusters (and the first available cluster number) for faster calculation of free space, and allocation of new data. These use sector 1 (FS Info), sector 6 (backup boot sector), and sector 7 (backup FS Info) traditionally. It isn't advisable to change these, but the backup sector and the FS Info sector offset can be moved (their block numbers are in the BPB). The rest of the reserved sectors are left blank.
After the reserved sectors is the FAT itself. The space consumed by this is entirely dependent on the number of clusters in the volume. FAT12 uses 1.5 bytes per cluster. FAT16 uses 2 bytes per cluster. FAT32 uses 4 bytes per cluster. Num_Clusters (+2 reserved clusters) * Entry_Size = FAT_Size. This is rounded up to an integer number of sectors. There are usually 2 copies of the FAT, but that is configurable in the BPB as well. The 2nd FAT is located at (0 + Reserved_Sectors + FAT_Sectors) sectors.
For FAT12/16, the next region is the Root Directory. It follows on the very next sector after the FATs. The number of entries is chosen when the file system is created, and each entry takes 32 bytes. Ergo, the size of the root directory is ((Num_Entries * 32) / Sector_Size). This is again rounded up to full sectors.
FAT32 does not use a dedicated region for the root directory, it's just allocated in the data region like any other directory. The BPB field that defines the number of root entries will be set to 0.
Finally, the data region. It starts at Cluster #2 and goes all the way up to ((Sectors_Total - (Reserved_Sectors + Root_Sectors + (FAT_Sectors * FATs))) / Sectors_Per_Cluster), rounded down to the nearest integer number of clusters.
FAT12 can contain 1 to 4084 clusters. FAT16 can contain 4085 to 65,524 clusters. FAT32 can contain 65,525 to 268,425,446 clusters. This is actually how you determine which FAT to use -- the number of clusters. It's not set explicitly anywhere in the BPB or any other place. (Although there is a text field in the BPB that says "FAT16" or whatever. It is not meant to be used authoritatively, but some tools -- like apparently sys.com -- will fail to work if it's not set correctly.)
Now, if you're trying to assure that the data region starts on a cluster boundary, you have to make sure that the reserved sectors, FATs, and root directory (if not FAT32) all take up exactly X cluster(s). This can be difficult to do, as the size of the FAT tables depends on the number of clusters. So, as you change the number of sectors available to be used as data clusters, it changes the size of the FATs, which changes the number of sectors available to be used as data clusters, and so on. I wrote a routine that does this iteratively to find the most efficient layout given a certain number of total sectors and the cluster size you want to use, but it does not attempt to align the data region by manipulating the number of reserved sectors. (It could, though.)