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