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 sectors. 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. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
