Disk block size

A long long time ago in a technology far away someone created hard disks with a block size of 512 bytes. The file systems using the disks grew to use block sizes of 1KB (1 kilobyte or 1024 bytes) then 4KB (4096 bytes) and larger. The disks never grew up to match the file systems. Demand improve disks now!

IBM invented the type of disk we use today. IBM made their own disks and used a block size of 4KB on their mainframe disks because that made the disks efficient and reliable. The retail disks, as pushed by Seagate and others, all used 512 bytes to fit early PC file systems designed for floppy disks.

0.5KB

Unix, Linux, and Windows never grew up. They continued using 512 bytes, 0.5KB, despite rapid increases in disk size. The operating systems introduced block allocation units, BAUs, and presented data to applications in bigger chunks. Linux uses 8KB chunks, 8192 bytes, but still have 512 bytes hard coded into the boot code and other areas. Microsoft NTFS uses mixed 1KB and 4KB in NTFS with the ability to expand the 4KB up to 128KB, giving you immense flexibility but when they transplanted NTFS from NT to Windows they forgot to make Windows compatible with anything other than the 4KB BAU plus they left the Windows code stuck with 512 byte for the boot code.

4KB

Back in 1993, when Microsoft released NT, I suggested to a lot of people in the Information Technology industry that we should start the change to 4KB by immediately bringing out disks with 1KB blocks. People could adjust their operating systems to work with both then put in auto detection of 4KB. 1KB would work with both the 1KB and the 4KB blocks in NTFS. I demonstrated the change would improve reliability, increase efficiency, and reduce the then significant processing overheads. I even offered a microcoded cache design to let operating systems start on 1KB disks using 512 bytes then change at a later date.

1998. An IBM task force recommends 4KB to IDEMA, the International Disk Drive Equipment and Materials Association.

2000. IDEMA form a Long Data Block committee.

2003. Seagate, Maxtor, Fujitsu, and Hitachi join in with a letter to Microsoft.

2004. Microsoft suggests 4KB support in the Longhorn version of Windows if the Phoenix BIOS developers add support.

2005. Phoenix support 4KB.

If you think information technology is fast moving, look at that 5 year delay before anyone in the disk manufacturing industry started thinking about the problem then add the fact that today, 11 years after their first recommendation, there are still no disks using bigger blocks.

IDEMA originally predicted new disks for 2006 and now they are saying it will be 2011. They say the disk decision makers are Seagate, Western Digital, Hitachi, Fujitsu, Toshiba, and Samsung but the previous big delay was caused in part by Microsoft.

But the fine detail is worse. The 2011 disks will emulate 512 bytes so that Microsoft can continue doing nothing for longer. 4KB disks without emulation will not appear until 2012. We get 1993 delivered in 2011 and the future has to wait until 2012.

8KB

Linux conquered the Web server world, Linux uses the Ext3 file system, and Ext3 uses 8KB BLUs. Disks should start the transition to 8KB. After the 19 year delay to get something bigger than 0.5KB, we should be working to a plan that includes 8KB.

Microsoft could change Windows to actually work with NTFS set to 8KB BLUs instead of just 4KB BLUs. Microsoft could change NTFS to automatically use 8KB as the minimum BLU on 8KB disks. Microsoft could put the 1KB small file storage into clusters of 4KB and 8KB. Some of these changes would be miniscule, work experience kid type work, assuming Microsoft have not written totally stupid stuff into their operating systems.

Conclusion

Starting with your first desktop computer or server purchase in 2011, demand 4KB disks and 4KB support in the BIOS. Test your operating systems with the new disks and provide feedback to your supplier if an operating system does not work with 4KB. In the case of Microsoft, you can point out they had 7 years to allocate a couple of programmers for a few weeks to fix the problem and during that period received from sales of operating systems about $175,000,000,000.00.