Exploring hard disk size limits about fdpp HOT 14 OPEN

Does this truncation happen even with
the redirector and your large disk
extensions?

from fdpp.

No, it's in FDPP's disk init stage so only affects block devices.

from fdpp.

Although I don't know what would happen if I had a linux disks > 2TiB that dosemu would like to convert to fatfs.

from fdpp.

So I guess it is supposed to work,
because, no matter of truncation,
there is a system area in the beginning
of an FS. And dosemu is allocating
the space sequentially, so the needed
files are accessible.
So I guess you only need to fix the
numbering problems?

from fdpp.

So I guess you only need to fix the
numbering problems?

I suspect the drive is invalidated because of can't use LBA partition without LBA support, perhaps the geometry truncation doesn't need to flip the drive into using CHS accesses. On the other hand how safe is it to shorten a disk's geometry when an existing filesystem on there may already extend into a now inaccessible region? Perhaps dosemu should just ignore disks greater than 2TiB instead?

from fdpp.

I am not actually sure.
I think if you mean a single-partition
hdimage, then it would be strange to
ignore. No matter how large the drive
is, or the partition is, the fatfs can't be
that big itself.
What exactly scenario is there that
fatfs is partially inaccessible?

from fdpp.

No matter how large the drive
is, or the partition is, the fatfs can't be
that big itself.

I agree if you are referring to dosemu's fatfs as that's only FAT16, but if you mean FAT in general then FAT32 can reach that size (just).

What exactly scenario is there that
fatfs is partially inaccessible?

Disk containing one FAT32 partition of size (2TiB - 512B) is shared (either as dual boot with Windows or as removable drive moved between machines). On FDPP/FreeDOS that's seen as too big and geometry accessible is only 8GiB, but filesystem extends beyond that. I suppose that if DOS were to write a file that crossed the 8GiB boundary, it would only be able to write a portion of it.

from fdpp.

But 8Gb is CHS-mode limit.
If we don't fall back to CHS
(which is a bug, right?), why
do we care about 8Gb?

from fdpp.

If we don't fall back to CHS
(which is a bug, right?), why
do we care about 8Gb?

Yes I think it's a bug to switch from LBA to CHS just because the disk is too big. It probably came about because early LBA implementations were seen as buggy and if any geometry oddities were encountered it was thought safer to use the CHS. Remembering of course that when LBA came out there were no multi-terabyte disks, and such large values were preposterous.
So if we remain in LBA mode, presumably we would only have to truncate the geometry to be the maximum disk offset that FDPP can reach with 32bit variables?

from fdpp.

I don't know the technical pit-falls.
But I think if we can, we should support
fat32 of any possible size. If that needs
a 64bit variables - why can't we do that?

from fdpp.

If that needs
a 64bit variables - why can't we do that?

Not sure how to use 64bit variables in FDPP, I get confused about what's 16bit code and what isn't. For instance I needed to change a printf('%d') for a ULONG parameter earlier and I expected to use '%ul' but the compiler showed me that ULONG is actually 'unsigned int'.

In the ticket I linked earlier there was some discussion about needing 64bit math helpers for each compiler (Watcom / Gcc). Now I don't expect that's the case with FDPP as we don't use those 16bit compilers, but what is required to change a uint32_t to uint64_t?

from fdpp.

With MBR partitioning you only need "33-bit LBA" at most because your partition start / hidden sectors and partition / file system size are both limited to 32-bit each. There was a FreeDOS kernel patch by Tom Ehlert floating around that added GPT support however, in that case the lower-level (DOS drive to int 13h sectors layout) handling should support the full 64-bits.

from fdpp.

ULONG is a 32bit type.
Which is why it is "unsigned int" on
64bit platforms (and unsigned long
on 16 or 32bit platforms).
But you can still use uint64_t or
long long.

from fdpp.

(DOS drive to int 13h sectors layout) handling should support the full 64-bits.

I hope at least the LBA subset of it,
already does.

from fdpp.