FAT maximums

[Torinde]

From what I read the following is supported:

• 256 sectors per cluster (non-standard usage of the 0 value)
• 128KB cluster size with 512B sectors - up to 8GB FAT16
• "LBA 33" for MBR with up to 4TB size with 512B sectors (with multiple partitions, of which the last one goes beyond 2TB)

What about bigger values?

• 128KB cluster size with up to 4KB sectors as supported by NT/XP - up to 8GB FAT16, up to 16TB FAT32
• 256KB cluster size with up to 2KB sectors as supported by NT - for 16GB FAT16
• sector size up to 32KB as supported by Linux
• sector size 64KB (maximum unsigned 2 byte value?)
• cluster size up to 16MB to match the 64KB sectors with 256 sectors per cluster. That will allow FAT16 up to 1TB, FAT32 up to 4PB?
• boot support for sectors above 512B and clusters above 128KB. That will allow MBR FAT32 up to 256TB (512TB if multiple partitions)?
• 65536 sectors per cluster (with that number "assigned" to 0 or 1 or 128 or some non-power-of-2 value in the 3rd byte of BPB) and 32MB cluster size (512B sectors). That will allow MBR FAT16 2TB partition.
• SFD format (Super-floppy Disk) non-partitioned disk format. The FAT volume starts at the LBA 0 of the physical drive without any disk partitioning.

[boeckmann]

Actually none of the things mentioned above is "supported" by the EDR kernel provided here, including the items having a check mark. Especially the use of 256 sectors per clusters is highly discouraged. It is an invention straight from hell, as is FAT+ ...

While the kernel might correctly deal with such file systems, it will never generate (default) BPBs with zero-encoded spc values by itself.

The only supported sector size for hard disks is 512 bytes.

[ecm-pushbx]

33-bit LBA is, as far as I'm aware, an invention on my side. lDOS boot does support this, but I'm not aware of any kernel that does.

[Torinde]

OK, since most of that isn't supported, how feasible is to add support for some of those?

In comparison with GPT - which approach is better for compatibility and which is easier to implement?

[boeckmann]

Implementing GPT support should not expose any significant compatibility problems, as MS-DOS simply does not "see" the GPT partitions. Worst case I can imagine is that the drive letters disagree between MS-DOS and a GPT enabled DOS.

[boeckmann]

The above of course only is true if the GPT partitions are guarded by a protective MBR, or a hybrid MBR/GPT layout exists. Hybrid setups are not that common, but the protective MBR should almost always exist.

[Torinde]

But can you go beyond 2GB/2TB FAT16/FAT32 with a protective MBR?

The only supported sector size for hard disks is 512 bytes.

Per Wikipedia:

DR-DOS supports booting off FAT12/FAT16 volumes with logical sector sizes up to 32 KB and INT 13h implementations supporting physical sectors up to 1024 bytes/sector.

If that's incorrect, then isn't it relevant to add 4K sector support - for compatibility with NT FAT16 partitions, XP FAT32 partitions and modern Advanced Format drives?

[boeckmann]

But can you go beyond 2GB/2TB FAT16/FAT32 with such setup?

The 2GB FAT16 limit is independent of the partitioning scheme, but 2^32-1 sectors should be the maximum size a MBR partition may have, which equals ~2TB when using a sector size of 512 bytes. A GPT partition may be larger. I have not investigated whether it's possible to create a FAT32 >2TB, as the inefficiency of the file system "forbids" to even thinking about it :)

[boeckmann]

If that's incorrect, then isn't it relevant to add 4K sector support - for compatibility with NT FAT16 partitions, XP FAT32 partitions and modern Advanced Format drives?

Accessing "advanced format drives" through its native sector size via INT13 BIOS calls will likely be prohibited by the BIOS not supporting this. At least I am not aware of a single BIOS that does.

As the EDR kernel is not per se incapable of dealing with disks having a sector size other than 512 bytes (this is a limitation of the internal hard disk driver having it hard-coded at some places), it might be possible with a custom driver accessing the disk directly via ATA commands, theoretically.

[Torinde]

FAT16 - so, with 128 sectors per cluster you can reach 4GB, but anything above requires either 256 sectors per cluster or larger than 512B sectors. That's supported by NT.
FAT32 - for MBR with more than 2TB (single partition) you need larger than 512B sectors. That's supported by 2K up to 8TB. Up to 16TB with 4K sectors (probably in Vista or Win7?).

I'm trying to find what's the maximum that DOS can get out of MBR or FAT16/32 inside GPT, which limit/parameter is feasible to extend beyond what was supported in the 1990s/2000s.

internal hard disk driver having it hard-coded at some places

Where is this driver? Outside the kernel file(s)?

[boeckmann]

If that's incorrect

I do not think that's incorrect in general. Earlier DR-DOS versions most likely were able to boot from such disks, especially floppy disks. As floppy and hard disks used by the PC standardized to 512 bps not many took care supporting sector sizes other than 512 bytes (for example, FreeDOS kernel has no support at all).

[boeckmann]

I'm trying to find what's the maximum that DOS can get out of MBR or FAT16/32 inside GPT, which limit/parameter is feasible to extend beyond what was supported in the 1990s/2000s.

Several 32-bit variables I guess. With the introduction of FAT+ for example some data structures were adapted. The result was broken compatibility (DR-DOS task manager for example does not run on FAT+ enabled kernels).

This commit might give some insight of what has to be changed. The commit makes FAT+ optional, shrinking some 64 values back to 32 bit.

internal hard disk driver having it hard-coded at some places

Where is this driver? Outside the kernel file(s)?

https://github.com/SvarDOS/edrdos/blob/main/drbio/disk.asm

[boeckmann]

[...] supporting sector sizes other than 512 bytes (for example, FreeDOS kernel has no support at all).

No support via its internal drivers, to be precise. Things like external RAM disk drivers etc. should work with different sizes, but I have not tried this by myself.

[boeckmann]

Many of the changes done when implementing FAT+ were to support FILES >2GB (or was it 4?!?). Accessing a file system beyond 2TB might not have that of an impact, as the >32 bit LBA values might be shielded by the disk driver from the rest of the system.

[Torinde]

So, it seems the preferable way forward will be to adapt the disk driver for larger sectors while keeping the Sectors per Cluster at 128?

Accessing a file system beyond 2TB might not have that of an impact, as the >32 bit LBA values might be shielded by the disk driver from the rest of the system.

32-bit LBA is enough for 16TB (4KB sectors) or even 256TB if sectors can grow to 64KB (is sector size utilized as a 2-byte unsigned value?)