Microsoft announced In January 2007 that Hard Disk manufacturers will soon start making large-sector IDE or SATA drives, I am not sure which. The articles I read were not specific. This means that the sectors are larger than 512 bytes, specifically 1024, 2048, and 4096 bytes. Your BIOS, drive controller chipset, and Operating System must support such drives. Usually this means a change of motherboard and a switch to Vista or 7. For Windows OS's, only certain models of Vista support it. These drives will suppply an emulation mode for 512-byte sectors, but performance suffers. When you buy a hard disk, check its specs first.

Windows Vista was supposedly the first Windows OS to support these large-sector drives, according to one article. since 7 is vista-based, it will probably support it too.

• Hitachi: As of July 2007, all Hitachi drives are all 512-byte sectors.
• Quantum(Seagate): as of July 2007, All the drive by default have 512 bytes sector size.
• Maxtor(Seagate): as of July 2007, All the drive by default have 512 bytes sector size.
• Seagate: as of July 2007, All the drive by default have 512 bytes sector size.
• Samsung: as of July 2007, all drives are 512-byte sectors.
• Western Digital: as of July 2007, tech support: "We currently do not produce any Large Sector drives nor do I know if we are going to produce any."

from the limitations page:

• NTFS: 2³²−1=4,294,967,295 files per volume. see off-hand reference.
• NTFS: max 2^64−1 clusters=18,446,744,073,709,551,615 clusters*32768bytespercluster=<512ZiB=604,462,909,807,314,587,320,320 bytes 256TiB maximum volume size [not so. see the next limitation below]

8/29/2009

2TB drives have come out.

the next size up (should take several months) should spark some sort of shift in PC's, because for one thing, large sectored drives will only work in Windows Vista, and will become a necessity after the 2TB drive. And because the MBR (master boot record) on a hard disk, a specially formatted section on the hard disk, cannot handle more than 2³²×512B=2199023255552B=2TiB. But that is with 512Byte sectors. that is a key number for some things, at least for a while. read on. (MBR's LBA is 32-bits, not 48 like in the current BIOS and EFI).

I used to not know if this would be solved by RAID-style drivers or what. in wikipedia's MBR entry it says that the BIOS loads and executes the MBR (it is tied to it, and the BIOS is built-into the motherboard). A solution has been implemented in x64 Itatium servers, the UEFI+GPT replacement for BIOS+MBR. it allows up to 128 64-bit partitions per disk. So is it up to the motherboard manufacturers to come up with a solution?

Currently only Windows Vista ("later release", turns out to be SP1) and probably Windows 7 have compatibility with UEFI+GPT. Maybe things would work if Windows only made the minor modification of using GPT as its partitioning scheme.

The current Microsoft solution to the problem appears to be to use larger sectored-drives. This means drives with sector sizes larger than 512 bytes (1024, 2048, 4096). this staves off the problem of the 32-bit LBA until a later date (microsoft has warned people of this), and the 32-bit LBA MBR can still be used. If the 32-bit LBA problem is going to be handled by increasing the size of sectors, which is a possibility, it delays the necessity of using the UEFI+GPT, until, as Microsoft has said, "UEFI has established itself as a standard". I remember Microsoft warned about large sectored disks coming. I had asked all the disk manufacturers about their use of large sectors, but all said they were currently using 512-byte sectors in their products. this will probably change with the 2.5TB disk if that is the next size up. who knows, maybe it will be 3TB.

I can imagine there is probably going to be a lot of software with hard-coded sector-sizes in them that will have to be rewritten because they will then break on the new drives. it will likely be disk management software. Even I used to hard-code 512-byte sectors in my software (like the diskwipe program). I had to break myself of the habit. why? it was just too much trouble to do the call to get the disk geometry and do the multiplications by something akin to bytes_per_sector using __int64 or some other large number type in all my calculations for disk sizes and number of sectors or number of bytes.

When EFI becomes more established as a standard, Microsoft will replace the [32-bit] BIOS with EFI. EFI includes the GPT.

IN ENGLISH:

the next size drive up from the 2TB drive will probably use large sectors. it will probably cause some mis-coded disk management software to break.

If you intend to buy one of those drives, You may need to purchase a newer version of the disk management software that you currently own, such as Norton 360 or Norton Systemworks, or possibly Partition Magic (it may report incorrect disk/partition sizes). you might want to wait a while after the larger hard drive comes out before you get the replacement software so the software companies have a chance to rewrite and test their newer version and sell it to you.

For Norton Systemworks or Norton 360 or other similar software that "automatically defrags" or fixes your hard disk (that isn't built-into Windows), you might want to disable or maybe uninstall that feature as quickly as possible before it has a chance to execute. As a workaround, instead of buying Norton 360, buy Norton Internet Security (if the number of PC's it is licensed for is agreeable). In Mcafee Total Protection it is called Computer Maintenance. look for something with a similar sounding name.

• GPT FAQ
• UEFI_Windows.docx (Word 2007)
• Unified Extended Firmware Interface support in Windows Vista
• Boot Configuration Data (BCD)
• UEFI Support and Requirements for Windows Operating Systems
• IDEMA big sector backgrounder (Microsoft Word 2003)
• IDEMA(R) Workgroup Completes Long Block Data Sector Standard ...
• t13 Large Sector Size Proposal
• series of articles from IDEMA on implementing large-sectored drives and controllers

Please note that Microsoft only listed 1024, 2048, and 4096 as large-sectors.

FOR DEVELOPERS

You should know that you should NOT hard-code 512-byte sectors into your programs. This is used to be an old time-tested method of doing things, but since SCSI drives came out with 1024-byte sectors, and now that Microsoft has warned that large-sectored drives are coming out, this practice cannot be used anymore.

Windows

#include <WinIoCtl.h>
BOOL GetDriveGeometry(int drive, DISK_GEOMETRY *pdg) {
	HANDLE hDevice; // handle to the drive to be examined
	BOOL bResult; // results flag
	DWORD junk; // discard results
//	char _devicename[] = "\\\\.\\A:";
	char _devicename[100];// = ;

//	_devicename[4] += drive;
	sprintf(_devicename, "\\\\.\\PhysicalDrive%d", drive);

	hDevice = CreateFile(_devicename, // drive to open
		0, // no access to the drive
		FILE_SHARE_READ | // share mode
		FILE_SHARE_WRITE,
		NULL, // default security attributes
		OPEN_EXISTING, // disposition
		0, // file attributes
		NULL
	); // do not copy file attributes
	if (hDevice == INVALID_HANDLE_VALUE) {// cannot open the drive
		return (FALSE);
	}
	bResult = DeviceIoControl(hDevice, // device to be queried
		IOCTL_DISK_GET_DRIVE_GEOMETRY, // operation to perform
		NULL, 0, // no input buffer
		pdg, sizeof(*pdg), // output buffer
		&junk, // # bytes returned
		(LPOVERLAPPED) NULL
	); // synchronous I/O
	CloseHandle(hDevice);
	return (bResult);
}

There is also a DISK_GEOMETRY_EX that requires the call IOCTL_DISK_GET_DRIVE_LAYOUT_EX.

BIOS calls (DOS/FreeDOS)

For those who use BIOS functions to access the hard disk, Int 13h, function 48h provides disk geometry, including sector size. this is the preferable method of calculating disk size and getting sector size if you are using BIOS calls.

Get drive parameters
Entry:
AH - 48h
DL - Drive number
DS:SI - address of result buffer.
Exit:
carry clear
AH - 0
DS:SI - address of result buffer
carry set
AH - error code
This function returns physical device parameters. It is mandatory regardless of the interface subset which is
supported. Table 3 defines the result buffer. On entry the first word of the result buffer must be the bufer length in
bytes.
[check out these offsets:]
...
4 Double word Number of physical cylinders. This is 1 greater than the maximum cylinder number. Use Int 13h Fn 08h to find the logical number of cylinders.
8 Double word Number of physical heads. This is 1 greater than the maximum head number. Use Int 13h Fn 08h to find the logical number of heads.
12 Double word Number of physical sectors per track. This number is the same as the maximum sector number because sector addresses are 1 based. Use Int 13h Fn 08h to find the logical number of sectors per track.
16 Quad word Number of physical sectors. This is 1 greater then the maximum sector number. If this
field is greater than 15,482,880 then word 2, bit 1 is cleared to 0.
*24 Word Number of bytes in a sector.
...

Phoenix Int13 enhanced spec. It seemed to work great on the ASUS machines with old AMI BIOS I had running DOS with the diskwipe software I wrote.

If you are using assembler, I can't help you out a lot on that except to tell you that you will need to study the code hard, especially if there are no comments. Just look for anywhere that the number 512 pops up. Registers get used a lot, so if you are making some sort of disk calculation, you will probably need to:

1. allocate a static buffer somewhere and keep it handy
2. push all the registers on the stack that int 13h function 48h touches
3. call int 13h function 48h
4. pop the registers off the stack in reverse order
5. push DS and SI or ESI on the stack
6. mov my_destination_register, [dword ptr:static_buffer+24+DS:SI]
7. pop SI or ESI and DS off the stack