stanwebber wrote on 2025-07-13, 13:06:

i read this whole thread & i'm still confused. did the OP ever get a cf card aligned to 2048 sectors to boot in his 386 machine? […]
Show full quote

i read this whole thread & i'm still confused. did the OP ever get a cf card aligned to 2048 sectors to boot in his 386 machine?

i'm running into this same issue right now with an early p54c pentium bios. is the limitation bios or dos related?

this CAN work with dos 7.1 & fat32 on an award kt133a bios. i partition either a sata ssd or cf card with gparted aligned to 2048 sectors and the os just boots. the only problem i ran into was dos not recognizing a logical drive in an extended partition unless it was cylinder aligned with dos tools.

now i have a fat16 1gb cf card that will not boot in my p54c pentium machine unless i partition it with dos fdisk. when previously partitioned with gparted aligned to 2048 sectors, dos had no problems recognizing the drive from a boot floppy--just no boot.

what is the magic for alignment? if rmprepusb is the answer, what is it doing differently that gparted isn't?

The moral of this whole thread is that there is no point to partition align FAT/FAT32 volumes to 2048 sectors. This approach works in case of NTFS since the metada is part of the file system but it does not work in case of FAT/FAT32 since the metadata/header is before the file system so proper alignment works differently
(from here: Re: MS-DOS with aligned partitions on CF card, is it possible?)

Falcosoft wrote on 2025-07-13, 13:24:

The moral of this whole thread is that there is no point to partition align FAT/FAT32 volumes to 2048 sectors. This approach works in case of NTFS since the metada is part of the file system but it does not work in case of FAT/FAT32 since the metadata/header is before the file system so proper alignment works differently
(from here: Re: MS-DOS with aligned partitions on CF card, is it possible?)

truth be told, i'm not sure i understand why it's important for ANY flash media to be sector aligned. this whole alignment business started with mechanical hdds switching to physical 4k sectors and using a translation layer to present 512b sectors to the system bios. does all flash media do the same thing?

stanwebber wrote on 2025-07-13, 13:06:

i read this whole thread & i'm still confused. did the OP ever get a cf card aligned to 2048 sectors to boot in his 386 machine?

Some time later i eventually found YSDDT. As far as i can confirm, it does what needs to be done - it realigns the FAT16 partition and DOS is able to boot from it after the alignment.
You need to use quite a lot of flags on the program to run it. Have a second screen with manual ready. With flash memory, do not forget 'fatusedonly' along with other flags!
Also, you sometimes need to override some parts of partition info using 'fatnew*' or 'fatuse*' flags.

It seems to be working, but i don't have long-term extensive experience with it, yet.

stanwebber wrote on 2025-07-13, 13:52:

truth be told, i'm not sure i understand why it's important for ANY flash media to be sector aligned. this whole alignment business started with mechanical hdds switching to physical 4k sectors and using a translation layer to present 512b sectors to the system bios. does all flash media do the same thing?

I never really thought about it before, but from https://en.wikipedia.org/wiki/Flash_memory:

One limitation of flash memory is that it can be erased only a block at a time.

I think block sizes are generally much bigger than 512 bytes, so I think writes can be expensive if they require an erase first. I imagine that would get even worse if your write isn't aligned, e.g. writing one FAT cluster requires you to read half the cluster from one block, half from another, erase both blocks, then rewrite them both.

Maybe this is why I find compact flash as a hard drive replacement doesn't perform as great as I'd expect? 😁

stanwebber wrote on 2025-07-13, 13:06:

...
what is the magic for alignment? if rmprepusb is the answer, what is it doing differently that gparted isn't?

I missed this part of your question.
The answer is that contrary to GParted RMPrepUSB besides partition alignment also makes sure that FAT/FAT32 data clusters start at aligned sectors/LBA addresses. GParted does not do this automatically.
And as @doshea pointed out above this can be also relevant in case of flash drives not just advanced format HDDs.

my bios was so finicky nothing i did could consistently get it to boot except the following:

- create new msdos partition table with gparted
- wipe reserved sectors with disk genius
- create hibernation partition with phdisk (likely optional)
- create fat16/32 partition with microsoft fdisk
- format with microsoft using /s flag (sys would proobably work as well)

i landed on this process after over a couple dozen other trial & error attempts. with this process i installed/reinstalled win95rtm, nt4 sp6, win2k & win98fe on 4 separate 1gb cf cards without a single hickup. ysddt looks like it can accomplish the same thing and more, but i don't know if i have the patience to look into it at this point.

needless to say nothing is aligned. i'm not so concerned about performance as the top mode of the ide controller is pio 4, but flash longevity is still of concern. the cf cards are labelled as industrial, but oddly they still have the removable flag set. not a concern for any of the operating systems i'm working with, but i thought all industrial cards were fixed hdd.

Guys, simply use Partition Magic 8.04, and set the drive up fresh with it

Tecchie wrote on 2025-09-16, 02:28:

Guys, simply use Partition Magic 8.04, and set the drive up fresh with it

Have you even read this thread?
Partition Magic 8.04 does nothing regarding FAT/FAT32 data cluster alignment...

Contrary to NTFS in case of FAT/FAT32 partition alignment is not enough to get optimal speed.
In case of NTFS metadata is part of the file system (MFT) but in case of FAT/FAT32 the metadata is before the file system and the size of metadata is not fixed but depends on the partition and cluster size.
In order to get optimal speed you need to get First FAT table, Second FAT table, Root Directory and most importantly the First file data (cluster 0) to begin at aligned LBA addresses.

I have used OFORMAT.COM in the past (Inside Windows 2003 SP2 Deployment Tools (deploy.cab) and XPSP3). It is an updated DOS8/ME format for OEMS dated 2006.
One of the new switches is the /A switch. It says "The new /A command causes OFORMAT to align FAT data clusters. Specifically, the /A:8 option can be used to format the volume so that the FAT data clusters are aligned at 4K boundaries"
This could be tested versus rmprepusb and benchmarked with an SD or SSD to see if it is as fast or faster.

It seems MS released these tools for oems to optimally convert from FAT32 to NTFS, but we might be able to use them to align a fat fromat to 4k clusters or greater (32k for large fat32 drives).

I also noticed another dos program in deploy.cab called Cvtarea.exe. Haven't used it yet but it mentions "to create a reserved, contiguous, placeholder file for a less fragmented and more efficient file system before you convert the hard disk to the NTFS file system".
Probably no use to us if you keep the drive as fat32.

https://www.betaarchive.com/wiki/index.php?ti … _Archive/321880

doshea wrote on 2025-07-19, 07:51:

I think block sizes are generally much bigger than 512 bytes, so I think writes can be expensive if they require an erase first. I imagine that would get even worse if your write isn't aligned, e.g. writing one FAT cluster requires you to read half the cluster from one block, half from another, erase both blocks, then rewrite them both.

Maybe this is why I find compact flash as a hard drive replacement doesn't perform as great as I'd expect? 😁

ATA disks can have an internal write-cache, usually disabled because the OS wants to preserve the guarantee that once the IRQ from the write comes in, that the data is guaranteed written even if the power goes out afterward. You can enable it with e.g. Linux hdparm but I haven't done much testing there, mostly since write-tests would needlessly add wear.

To summarize this thread in general,
The DOS MBR wants partitions to be cylinder-aligned, except that the very first partition can is one track into the disk.
Because of historical CHS/translation accidents, cylinders are on very odd (255*63 sector) boundaries on substantially-sized disks, and the first track is 63 sectors into the disk--odd numbers.
Modern partitioning tools ignore DOS requirements and don't bother with cylinder-aligning partitions. Linux tends to megabyte-align them for example (helping with flash blocks mentioned above).
Modern file systems assume the partition containing them is already aligned, and so keep their data structures aligned too. FAT doesn't care about this, and is perfectly happy to start an important data structure, or the data area, on oddball sectors like 19 or 33 (in case of a floppy I just checked). So even if a FAT partition starts on a megabyte, 64K, or 4K boundary, unaware FAT formatting tools will happily mis-align data structures once again.
That's why aligning a FAT partition requires a tool that is filesystem-aware, to pad these data structures so that the FAT/data area start on a nice even boundary, not just aligning the partition containing it.

I've been trying out RMPrepUSB (v2.1.746) and Microsoft's OFORMAT.COM (XPSP3 deploy.cab - dated 2006)
to format and align a 120GB SSD in FAT32 (32KB cluster size).

Results with RMPrepUSB (i'm only showing the differences produced by USBInfo.txt for both)

Reserved Sectors before first FAT = 46 (002Eh)
Total Log. Sectors (big) = 234418432 (0DF8F100h)
Log. Sectors per FAT = 28617 (00006FC9h)

First FAT begins at LBA 2094
Second FAT begins at LBA 30711
Root Directory begins at LBA 59328
First file data (cluster 0) begins at LBA 59392
----------------------------------------------------

Results with OFORMAT.COM /A:64 (this has to be run in realmode DOS)

Reserved Sectors before first FAT = 32 (0020h)
Total Log. Sectors (big) = 234436608 (0DF93800h)
Log. Sectors per FAT = 28656 (00006FF0h)

First FAT begins at LBA 2080
Second FAT begins at LBA 30736
Root Directory begins at LBA 59392
First file data (cluster 0) begins at LBA 59456
--------------------------------------------------

Oformat FAT32 data structures all appear aligned (divisible by eight).

RMPRepUSB, both FATS are not aligned.
In the options for RMPRepUSB I only selected MS-DOS for bootsector and FAT32 for filesystem, no other options selected.

Riikcakirds wrote on 2025-10-09, 23:36:

I've been trying out RMPrepUSB (v2.1.746) and Microsoft's OFORMAT.COM (XPSP3 deploy.cab - dated 2006) to format and align a 120G […]
Show full quote

I've been trying out RMPrepUSB (v2.1.746) and Microsoft's OFORMAT.COM (XPSP3 deploy.cab - dated 2006)
to format and align a 120GB SSD in FAT32 (32KB cluster size).

Results with RMPrepUSB (i'm only showing the differences produced by USBInfo.txt for both)

Reserved Sectors before first FAT = 46 (002Eh)
Total Log. Sectors (big) = 234418432 (0DF8F100h)
Log. Sectors per FAT = 28617 (00006FC9h)

First FAT begins at LBA 2094
Second FAT begins at LBA 30711
Root Directory begins at LBA 59328
First file data (cluster 0) begins at LBA 59392
----------------------------------------------------

Results with OFORMAT.COM /A:64 (this has to be run in realmode DOS)

Reserved Sectors before first FAT = 32 (0020h)
Total Log. Sectors (big) = 234436608 (0DF93800h)
Log. Sectors per FAT = 28656 (00006FF0h)

First FAT begins at LBA 2080
Second FAT begins at LBA 30736
Root Directory begins at LBA 59392
First file data (cluster 0) begins at LBA 59456
--------------------------------------------------

Oformat FAT32 data structures all appear aligned (divisible by eight).

RMPRepUSB, both FATS are not aligned.
In the options for RMPRepUSB I only selected MS-DOS for bootsector and FAT32 for filesystem, no other options selected.

Hi,
It's interesting but I think for ideal performance the most important metric is the data cluster alignment (FAT tables are only in the 10 Megabytes range).
Data clusters are properly 4K aligned in both cases but in case of RMPRepUSB the alignment is actually 1024K while in case of OFORMAT it's only 32K ( most likely it's because of the cluster size defined by the /A:64 parameter) .
Bigger might be better for flash media since internal atomic blocks are usually bigger than 4K.
Have you run some benchmarks for the 2 cases?

@EDIT:
I have tried experimenting with OFORMAT on real DOS 7.1(Win98 SE) but it reported 'Incorrect MS-DOS version'.
Do you know what kind of DOS version it expects? What is the result of the 'ver' command on your DOS version where OFORMAT worked?

Falcosoft wrote on 2025-10-10, 06:24:

Hi, It's interesting but I think for ideal performance the most important metric is the data cluster alignment (FAT tables are o […]
Show full quote

Hi,
It's interesting but I think for ideal performance the most important metric is the data cluster alignment (FAT tables are only in the 10 Megabytes range).
Data clusters are properly 4K aligned in both cases but in case of RMPRepUSB the alignment is actually 1024K while in case of OFORMAT it's only 32K ( most likely it's because of the cluster size defined by the /A:64 parameter) .
Bigger might be better for flash media since internal atomic blocks are usually bigger than 4K.
Have you run some benchmarks for the 2 cases?

Not sure what you mean when you say RMPRepUSB the alignment is 1024k while OFORMAT is 32KB? Could you explain that. Do you mean the partition offset?
To be clear I created the partition for OFORMAT on Win10 (1MB aligned) then formatted it in realmode DOS with OFORMAT.
One thing to mention about OFORMAT, it does restrict you to Microsoft's FAT32 default cluster sizes:
512MB to 8GB - 4 KB
8GB to 16GB - 8 KB
16GB to 32GB - 16 KB
Larger than 32GB - 32KB

Running OFORMAT /A:8 on my 120GB SSD still forced a 32KB cluster size. So I formatted again with the /A:64 switch just to make sure 32KB cluster size was aligned.

Falcosoft wrote on 2025-10-10, 06:24:

@EDIT:
I have tried experimenting with OFORMAT on real DOS 7.1(Win98 SE) but it reported 'Incorrect MS-DOS version'.
Do you know what kind of DOS version it expects? What is the result of the 'ver' command on your DOS version where OFORMAT worked?

Use Setver OFORMAT.COM 8.00
It's an updated DOS8/ME format but it will run fine in DOS7.1 after using setver.

About benchmarks, I tried a quick Robocopy test (just the /E switch) and copied an 8GB mixed filesize folder with around a thousand files to the empty SSD.
RMPRepUSB FAT32 formatted SSD - 1 Min 57 seconds
OFORMAT FAT32 formatted SSD - 1 Min 45 seconds.

Riikcakirds wrote on 2025-10-11, 23:38:

...
Not sure what you mean when you say RMPRepUSB the alignment is 1024k while OFORMAT is 32KB? Could you explain that. Do you mean the partition offset?

Hi,
No, it's not about the partition offset but the data cluster alignment. 1024k alignment means that the LBA address of the 1st data cluster is divisible by 2048. So if a flash media had 1 megabyte sized real sectors the FAT32 volume would still be properly aligned. And similarly OFORMAT's 32KB alignment means that the LBA address of the 1st data cluster is divisible by 64 which ensures proper alignment for media up to 32K real sector sizes.

@Edit:

Use Setver OFORMAT.COM 8.00
It's an updated DOS8/ME format but it will run fine in DOS7.1 after using setver.

Thanks, it worked!
According to your and also my benchmark results it seems that media formatted with OFORMAT tends to be marginally faster. I tested with 4K advanced format HDD instead of SSD and in this case the difference is smaller but both formatting methods provide big improvements over standard formatting.

1 GB ISO copy results:
RMPRepUSB: 11.5 sec
OFORMAT: 10.7 sec
Win98SE format: 19.8 sec

The ~80GB partition was the same and properly aligned in all cases.

So it seems OFORMAT is the ultimate tool for properly formatting FAT32 volumes!

So, to recap, we partition the media in Windows 11 with FAT32 and then boot into DOS and format the media with OFORMAT?

Stretch wrote on 2025-10-12, 12:22:

So, to recap, we partition the media in Windows 11 with FAT32 and then boot into DOS and format the media with OFORMAT?

Yes, I think so.
But if you do not use WinMe/DOS 8.0 then do not forget to install setver in config.sys (DEVICE=C:\PathOfCommands\setver.exe) and then use the 'Setver OFORMAT.COM 8.00' command and then reboot.
Finally you should use OFORMAT /A:8 for 4K aligned FAT structures and data clusters or rather OFORMAT /A:64 for flash media resulting in even more optimal (32K) alignment.

Falcosoft wrote on 2025-10-12, 04:26:

Riikcakirds wrote on 2025-10-11, 23:38:

...
Not sure what you mean when you say RMPRepUSB the alignment is 1024k while OFORMAT is 32KB? Could you explain that. Do you mean the partition offset?

Hi,
No, it's not about the partition offset but the data cluster alignment. 1024k alignment means that the LBA address of the 1st data cluster is divisible by 2048. So if a flash media had 1 megabyte sized real sectors the FAT32 volume would still be properly aligned. And similarly OFORMAT's 32KB alignment means that the LBA address of the 1st data cluster is divisible by 64 which ensures proper alignment for media up to 32K real sector sizes.

I understand what you mean now. Larger could be better as compared to mechanical HDs we have to deal with nand storage page sizes between 4KB to 16 KB ( larger than mechanical HD) and then Block sizes (multiple of page sizes - the smallest area than can be deleted) between 512 KB to 8 MB. So larger than 32KB in some cases could be better if we knew what the manufacturers used on specific nand devices. The manufactures seem to not publish the page/block sizes.
Edit
I also just tested OFORMAT without the /A option to check what it does. On a 1MB aligned partition it gives an identical result to RMPrepUSB, the same LBA values.
Both FAT tables are NOT 4k aligned. The root Directory and First file data cluster are aligned. So it confirms OFORMAT with the /A option might be the only known tool so far that does align all the FAT32 data structures.

I searched Microsoft archive about OFORMAT.COM and found this:
https://web.archive.org/web/20021213164833/ht … stallP.asp#img1
which explains the reason for the tool and what the the other dos program CVTAREA does.

Also I found interesting that Windows 11 has finally removed the 32GB FAT32 format limit, allowing a FAT32 format up to 2TB
https://www.theverge.com/2024/8/16/24221635/m … imit-windows-11

I haven't tried this yet, but wonder if Microsoft's format in Win11 will properly align the FAT32 Data structures.

stanwebber wrote on 2025-07-13, 13:52:

truth be told, i'm not sure i understand why it's important for ANY flash media to be sector aligned. this whole alignment business started with mechanical hdds switching to physical 4k sectors and using a translation layer to present 512b sectors to the system bios. does all flash media do the same thing?

It's actually more of filesystem clusters being aligned to nand-flash erase block boundaries. The purpose is to prevent the case where a cluster steps across the boundary of 2 erase blocks.

Also, someone else was commenting about nand-flashes being erased just before writing - not entirely correct. When writing data to the nand array, the controller actually merges original block data with the modified data, writes the new version of the modified block and invalidates the old one, without erasing it (nand controllers allow over-writing 1s to 0s in the block metadata, so the block state can be changed just a little bit more without actually executing erase command). When the controller needs empty pages but none are available, it looks for the ones with lowest write count end erases them so they can be reused. So, erasing is more of a garbage collection activity than a data write step.