Hi Scott,

> I see that the FreeDOS format command has a /A option to use 4k sector 
> formatting.

That is not actually 4k sector formatting, as the help explains:

>  /A         Force metadata (reserved/boot sectors and FAT32s together) to be a
>             multiple of 4k in size. The NTFS converter of WinXP wants that.

In addition, if you partition (with FDISK for DOS, Windows or Linux or
a more powerful tool like GPARTED which also is available on boot CD
ISO image) your disk to make sure that partitions start at multiples of
4 kB, this also is a step towards putting your data clusters on 4 kB
aligned locations. This typically makes modern SSD disks happy because
their storage chips internally have 4 kB or 8 kB "sector size" so they
are faster if access happens in multiples of that. However, they still
LOOK like disks with 512 byte sectors to the BIOS and to DOS.

Another issue are modern harddisks above 2 Terabytes which have or can
be switched / jumpered to 4 kB SECTOR size instead of 512 bytes which
is a sort of hack to work with older versions of Windows which do not
support more than 2^32 sectors because they do not support partitioning
schemes other than the classic MBR partition table.

> Have any of the underlying I/O paths or built-in tools for 
> writing/cloning/copying/etc been updated to understand the new 
> generation of large drives that use 4K physical sectors but still accept 
> 512b interactions? (Think Western Digital Caviar Green 3TB drives).

Many DOS tools implicitly assume that sectors are 512 bytes. Actually
even the FreeDOS kernel itself does that, as other sector sizes were
extremely rare in the past. Only for example a special asian floppy
size and certain optical rewriteable media would use larger sectors,
so before 3 TB harddisks existed, you only "felt" this limitation of
the FreeDOS kernel for ramdisks: Some ramdisk drivers support other
sector sizes in principle, but not in FreeDOS because that does not.

To be honest, I think the BETTER way for FreeDOS to support huge disks
would be to support modern EFI GUID partitioning schemes while keeping
low level sector size unchanged at 512 bytes. You can still combine
this with FDISK and FORMAT options to make many data structures both
aligned and sized to multiples of 4 kB which can help with performance
if the hardware sector size of a huge harddisk is really 4 kB but it
is easy for the harddisk to still allow access in 512 byte software

As Jack (thanks for contributing to this thread) pointed out, there
are several possible limitations of disk size:

- old disks and BIOSes could support only 2^28 sectors LBA

- old disks and BIOSes could support only 2^32 sector implementations

- even if LBA for 2^48 sectors is supported, MBR partitions must be
  entirely in the first 2^32 sectors

- FAT32 supports up to 2^28 clusters of 32 kB (sometimes 64 or 128)
  each in one drive letter, which would be 8 TB. However, you can
  expect that performance will be somewhat mediocre for huge drives.

- FAT32 does not officially support files above 4 GB per file but a
  number of semi-compatible workarounds in drivers and OSes exist.

Of course the question is what you plan to do with a 3 TB disk in DOS.
If you only want to put a 3 GB DOS partition on your 3 TB disk, even
a non-LBA partition in the first 8 GB would work, even in some cases
allowing to mix EFI GUID partitioning for the whole disk with a view
on some of the partitions in the first 2 TB with help of classic MBR.

For reference, here is the data structure used for EFI GUID partitions
which are "partition type 0xef with all CHS information ignored" when
you look at them from the classic MBR partition point of view:

> Header, padded to sector size or next power of 2:
> qword 0x5452415020494645 / EFI PART
> dword 0x00010000 version
> dword header size
> dword header crc32
> dword 0
> qword lba address of THIS sector
> qword lba address of alternate header(?)
> qword first data block of partition?
> qword last data block of partition?
> 16 bytes GUID to uniquely identify disk
> qword lba address of GUID partition entry array
> dword array size
> dword array crc32
> padding

> Partition entry, 128 bytes each:
> 16 bytes partition type (0 if unused)
> 16 bytes GUID to very uniquely identify partition
> qword lba address of partition start
> qword lba address of partition end
> qword attribute bits (only low bit required?)
>   (high word reserved, middle 47 bits undefined?)
> 72 bytes UTF-8 (correct?) partition name string

Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
Freedos-user mailing list

Reply via email to