I have been wondering if something is hinky in partition managers for using disks on older systems post ~127GB support.... I had problems getting a turn of the milennium board to see a disk I was partitioning with Lubuntu 20.x then 18.x and finally tried an older based Puppy linux that might have had circa 2005 codebase and it half worked with the gparted in that one, but I still had to use
fdisk /cmbr 2
2 was because it was 2nd drive I think, to get it useable on the duron board.

The regular MBR should be fine and not care at all: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm#CODE

I think the only reason it was customary to align partitions to cylinders is because LLF-time bad block non-remapping merely disabled entire tracks for simplicity?

However, if you're resizing (and simultaneously moving) partitions afterwards, there are some things that at least on paper are likely to be wrong - for one, in most versions of DOS, io.sys and msdos.sys must be the first files in both the filesystem and, IIRC, even in raw location;

Then you have various values in the BPB related to the filesystem's size and start position, like the "hidden sectors" (amount of sectors before the partition), which I know some disk utilities don't change… further complicated, of course, by the complex relationship (euphemism) between the BPB and certain DOS versions 😀 🙁

I could replicate the issue with a fresh install (i.e. io/msdos.sys right where the installer wants them; no moving stuff around after the fact) of MS-DOS 6.22 on a 200MB (i.e. no large-size drive issue) in QEMU. Used Linux' fdisk to create the partition table, everything else was DOS' doing.

I agree it's not ideal... but then again, does it matter all that much? Every partition after the first one can still be aligned, so we only put stuff on there that mostly needs to be read, everything else can go to one of the "good" partitions.

edit: fwiw, FreeDOS doesn't like it either.

elszgensa wrote on 2024-02-25, 20:19:

Used Linux' fdisk to create the partition table, everything else was DOS' doing.

Oh right, classic Linux fdisk (when it didn't have limited support for GPT/Sun partitions, and CHS still had 2nd instead of 5th class support) had a long warning in the manpage saying that you need to blank the first few sectors of any partition to be formatted with DOS because some implementations would trust whatever's in the BPB, meaningful or not, over than what's in the MBR…

What about using Ranish? (I suspect it also aligns to cylinders though)

That's why I often used S0Kill, it clears track 0.
It can remove LiLo and other persistent bootloader tools, too.

Re: IDE to Compact Flash as MS-DOS boot drive.

It's pretty pointless though. How do plan to keep the files "aligned" with a variable FAT size?

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.
On Windows you can use RMPrepUSB to check if this is the case.
More info:
https://msfn.org/board/topic/151798-does-fat3 … n-its-clusters/
https://rmprepusb.blogspot.com/2014/06/increa … d-or-flash.html

Falcosoft wrote on 2024-02-26, 07:46:

Contrary to NTFS in case of FAT/FAT32 partition alignment is not enough to get optimal speed. In case of NTFS metadata is part o […]
Show full quote

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.
On Windows you can use RMPrepUSB to check if this is the case.
More info:
https://msfn.org/board/topic/151798-does-fat3 … n-its-clusters/
https://rmprepusb.blogspot.com/2014/06/increa … d-or-flash.html

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage!
For example the root directory table (even in FAT32 that it doesn't precede data but it's part of them) adjusts depending on the number of entries in the root directory, moving the start of actual files. The partition might look aligned, but your files won't be.

So even if you manage to somehow get everything correctly aligned, unless it's a read-only partition it won't stay like that.

konc wrote on 2024-02-26, 08:17:

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage! […]
Show full quote

Falcosoft wrote on 2024-02-26, 07:46:

Contrary to NTFS in case of FAT/FAT32 partition alignment is not enough to get optimal speed. In case of NTFS metadata is part o […]
Show full quote

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.
On Windows you can use RMPrepUSB to check if this is the case.
More info:
https://msfn.org/board/topic/151798-does-fat3 … n-its-clusters/
https://rmprepusb.blogspot.com/2014/06/increa … d-or-flash.html

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage!
For example the root directory table (even in FAT32 that it doesn't precede data but it's part of them) adjusts depending on the number of entries in the root directory, moving the start of actual files. The partition might look aligned, but your files won't be.

So even if you manage to somehow get everything correctly aligned, unless it's a read-only partition it won't stay like that.

Hi,
I do not think this is exactly the case. In case of FAT-16 the size of the root directory table is fixed and pre-allocated at creation time. In case of FAT-32 the root directory table is not fixed and it is in the data region as you said but according to my experiences enough size are reserved to not change the start of the first file data (cluster 0) even after long usage. E.g. my FAT32 4K drive that is in active usage for many years still shows the same starting addresses of FAT32 regions as at creation time. I have and old post about this driver here on vogons from 2018:
Re: Benchmarks: HDD vs. CF vs. true SSD on Tualatin rig
And this drive still shows the same addresses as in 2018:

Hi! How about simply using an NTFS or HPFS partition for DOS?
There are IFS like drivers for DOS.

HPFS Access
https://hobbes.nmsu.edu/?detail=%2Fpub%2Fdos% … Access_1-02.zip

NTFSDOS Professional
https://en.wikipedia.org/wiki/NTFSDOS#NTFSDOS_Professional

Datapol NTFS4DOS
https://msfn.org/board/topic/30998-datapol-ntfs4dos/

Falcosoft wrote on 2024-02-26, 09:46:

Hi, I do not think this is exactly the case. In case of FAT-16 the size of the root directory table is fixed and pre-allocated a […]
Show full quote

konc wrote on 2024-02-26, 08:17:

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage! […]
Show full quote

Falcosoft wrote on 2024-02-26, 07:46:

Contrary to NTFS in case of FAT/FAT32 partition alignment is not enough to get optimal speed. In case of NTFS metadata is part o […]
Show full quote

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.
On Windows you can use RMPrepUSB to check if this is the case.
More info:
https://msfn.org/board/topic/151798-does-fat3 … n-its-clusters/
https://rmprepusb.blogspot.com/2014/06/increa … d-or-flash.html

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage!
For example the root directory table (even in FAT32 that it doesn't precede data but it's part of them) adjusts depending on the number of entries in the root directory, moving the start of actual files. The partition might look aligned, but your files won't be.

So even if you manage to somehow get everything correctly aligned, unless it's a read-only partition it won't stay like that.

Hi,
I do not think this is exactly the case. In case of FAT-16 the size of the root directory table is fixed and pre-allocated at creation time. In case of FAT-32 the root directory table is not fixed and it is in the data region as you said but according to my experiences enough size are reserved to not change the start of the first file data (cluster 0) even after long usage. E.g. my FAT32 4K drive that is in active usage for many years still shows the same starting addresses of FAT32 regions as at creation time. I have and old post about this driver here on vogons from 2018:
Re: Benchmarks: HDD vs. CF vs. true SSD on Tualatin rig
And this drive still shows the same addresses as in 2018:

You are correct, I had to refresh my memory and what I wrote doesn't apply for FAT16. In FAT16 the root directory table size is indeed fixed and pre-allocated, hence the 512 max number of files in the root.

But I will insist for FAT32, it starts with a default size and it can grow to the max number of files in any folder (65535), the limitation of FAT16 is lifted. Under normal use (like yours I assume) it probably won't grow. But it'll be interesting to see what happens if some script creates 65000 files in the root directory 😉 I'm intrigued to play with it.

konc wrote on 2024-02-26, 10:24:

Falcosoft wrote on 2024-02-26, 09:46:

Hi, I do not think this is exactly the case. In case of FAT-16 the size of the root directory table is fixed and pre-allocated a […]
Show full quote

konc wrote on 2024-02-26, 08:17:

Exactly, and furthermore the size of the metadata not only depends on clusters and sectors number, but also changes with usage!
For example the root directory table (even in FAT32 that it doesn't precede data but it's part of them) adjusts depending on the number of entries in the root directory, moving the start of actual files. The partition might look aligned, but your files won't be.

So even if you manage to somehow get everything correctly aligned, unless it's a read-only partition it won't stay like that.

Hi,
I do not think this is exactly the case. In case of FAT-16 the size of the root directory table is fixed and pre-allocated at creation time. In case of FAT-32 the root directory table is not fixed and it is in the data region as you said but according to my experiences enough size are reserved to not change the start of the first file data (cluster 0) even after long usage. E.g. my FAT32 4K drive that is in active usage for many years still shows the same starting addresses of FAT32 regions as at creation time. I have and old post about this driver here on vogons from 2018:
Re: Benchmarks: HDD vs. CF vs. true SSD on Tualatin rig
And this drive still shows the same addresses as in 2018:

You are correct, I had to refresh my memory and what I wrote doesn't apply for FAT16. In FAT16 the root directory table size is indeed fixed and pre-allocated, hence the 512 max number of files in the root.

But I will insist for FAT32, it starts with a default size and it can grow to the max number of files in any folder (65535), the limitation of FAT16 is lifted. Under normal use (like yours I assume) it probably won't grow. But it'll be interesting to see what happens if some script creates 65000 files in the root directory 😉 I'm intrigued to play with it.

Yes, I think you are right (according to my test the starting addresses do not change at all: additional entries are simply added to normal data region). But as you can see from the data of my drive starting from the 1st data sector all addresses are separated by cluster sized units (in my case cluster size is 64 blocks = 32k). Since the root directory table is already part of the data region it can only grow granularly (by cluster sized units). So if the 1st data address is properly 4K aligned then proper alignment cannot change even if some regions have to grow provided your cluster size is at least 4K aligned (always guaranteed in case of realistically sized FAT32 volumes).

So overall I think in case of FAT-32 you only have to make sure that FAT tables and starting of data area (includes root directory entries) are properly aligned at creation time. Partition alignment alone does not make a difference. Data clusters have to be aligned instead. For proper FAT-32 4k alignment this means that the 1st data cluster has to be at an LBA address that is divisible (at least) by 8. Later even if root directory entries grow the alignment cannot be ruined (confirmed by test)

@Edit:
Your suggested test is done (only 21790 directories are made since it takes a long time to make more and I think making more is not too realistic):

As you can see the alignment and even the starting addresses have not changed.

Falcosoft wrote on 2024-02-26, 11:22:

Since the root directory table is already part of the data region it can only grow granularly (by cluster sized units). So if the 1st data address is properly 4K aligned then proper alignment cannot change even if some regions have to grow provided your cluster size is at least 4K aligned (always guaranteed in case of realistically sized FAT32 volumes).

Very good point, it seems that you are correct again and initially aligning the data region is enough.

Which tool are you using that can provide the data region start? I won't bother to align anything on FAT machines, but I'd like to play with it

konc wrote on 2024-02-26, 12:21:

Falcosoft wrote on 2024-02-26, 11:22:

Since the root directory table is already part of the data region it can only grow granularly (by cluster sized units). So if the 1st data address is properly 4K aligned then proper alignment cannot change even if some regions have to grow provided your cluster size is at least 4K aligned (always guaranteed in case of realistically sized FAT32 volumes).

Very good point, it seems that you are correct again and initially aligning the data region is enough.

Which tool are you using that can provide the data region start? I won't bother to align anything on FAT machines, but I'd like to play with it

AFAIR, at that time for the mentioned drive I used mkfs in Linux, but nowadyas under Windows (mainly for flash media) I always use RMPrepUSB. RMPrepUSB also has ALLDRIVES mode in settings so you can use it for normal HDD/SSD:

BTW, in case of the mentioned Advanced Format/4K WD 1GB HDD this was not just a theoretical experiment. Without proper FAT-32 alignment it produced exactly half of the expected sustained write speed. So proper alignment had/has very noticeable speed improvement.

PS:
This 4k aligned FAT-32 HDD volume is also DOS bootable (currently working with DOS 7.1 from Win98 SE). I do not think CF cards can be any different. So answering the OP's question: yes, MS-DOS with aligned partitions and aligned clusters are possible for HDD/SSD and flash drives. For CF cards with a 386DX: I do not know, I have not tested it personally. You should give RMPrepUSB a chance.

Falcosoft wrote on 2024-02-26, 12:44:

AFAIR, at that time for the mentioned drive I used mkfs in Linux, but nowadyas under Windows (mainly for flash media) I always use RMPrepUSB. RMPrepUSB also has ALLDRIVES mode in settings so you can use it for normal HDD/SSD:

Thanks, for the instructions too. I'll experiment with the data region start out of curiosity

Great thread here 😀
Thanks for recommending RMPrepUSB tool @Falcosoft!

In the past I prepared my CF cards by hand with different tools on modern PC before plugging it into my DOS 7.10 PC.

IIRC I aligned the first partition to start at sector 1024.
Afterwards when FAT32 formatting I choosed cluster size according to MS recommendations (https://support.microsoft.com/en-us/topic/des … 63-e4846a878d31).
So, for my actual 128GB CF it is 32K cluster size.

Until today I'm not sure if this is the right way to do. You can read alot of different opinions regarding aligning position, cluster size etc.

RMPrepUSB seem to be the only tool I need for this in the future 😀
It seems heavily optimized because the author did experiment alot with settings and speed optimizations.

For my next DOS machine using MS-DOS 7.10 with FAT32 formatted 128GB SSD (via StarTech SATA->IDE adapter) I will go this route:

1. dummy format SSD with FAT32 file system so it is accessable as drive c: for next step (on modern PC).
2. run S0Kill on SSD (floppy boot into Win98 command line)
3. Format SSD with RMPrepUSB using settings "MS-DOS bootable" and FAT32 file system
4. check if Rudolph R. Loew's TRIM.EXE is running in that combination and put it in autoexec.bat

Maybe steps 1-2 are not neccessary but just to be sure everything is wiped.

Same here, thanks for recommending RMPrepUSB.

I've been too busy with other stuff, but i also can confirm that this is the one tool that i now use to prepare my CF cards for old computer. I've used it on 512MB CF FAT16, 8GB CF FAT32 and 128GB SSD FAT32 successfully now. It just works.

I still need to play around with some older computers, just in case. Current tests of using those CF/SSD drives were done on SLOT1 machine. I'm currently working on Toshiba T3200/40, a 286-based machine, which is getting a 512MB CF card. We'll see, how successful I'll be. 😀

@crusher, i'm basically skipping the points 1 and 2 and just go with 3. I've read about the DOS TRIM program, but haven't had time to play with it yet.

GigAHerZ wrote on 2024-06-24, 10:27:

@crusher, i'm basically skipping the points 1 and 2 and just go with 3. I've read about the DOS TRIM program, but haven't had time to play with it yet.

You can find it here:

https://rloewelectronics.com/

amongst other very useful tools and patches.
It is a good way for trimming SSDs under DOS (and Windows).
If it's working depends on a lot of factors (chipset, controller, disk type) and/or the combination of it.

I use it for my Windows 98 PC with 128GB FAT32 SSD (Samsung Evo) where TRIM.EXE is executed before Windows start via autoexec.bat.
It's working very well.

//Edit:
Be sure to verify that the trim process really worked. Don't rely on just a message.
I've had several tools on my XP PC that report "success" but haven't trimmed a single bit.
If you need help on how to verify see this:
Re: Corruption issue when using rloew's TRIM.EXE (TRIM utility for DOS) with FreeDOS FDISK 1.2.1/1.3.1 partitioned DISK

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?