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, BAU,s 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.




Comments
Every version of Windows
Every version of Windows released since IDEMA finalized the 4096 byte standard (in March 2006: http://idema.org/_smartsite/modules/local/data_file/show_file.php?cmd=download&data_file_id=1446) supports that new standard.
That is to say, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, all support it.
The problem is MS's pre-2006 operating systems, namely Windows XP.
So I'm not quite sure why you're being so critical or claiming they held back the industry; they had shipping software within 8 months, which isn't that bad, surely? The announcement came pretty late in the Vista development cycle, but they still did the work.
Sticking with 4 kiB (rather than 8 kiB) is also reasonable, given that it's still x86's preferred page size. Since I/O to the disk is often in page-sized chunks (any demand-paged I/O is in page-sized chunks, for example) making the disk operate in page-sized chunks seems fair.
Software is ready. It has been ready for some years. It's hard disk vendors that are dragging their feet. If the ineptitude of BIOS vendors wasn't making the partition table a continued headache (2^32 512 byte sectors causes a hard limit of 2 TiB per partition, and prevents any partition from starting beyond the first 2 TiB--problems that the long overdue switch to EFI + GPT would solve instantly), I doubt they'd be moving for another few years yet, in spite of error recovery shortfalls.
Microsoft could have jumped in 2003
4KB makes sense in Windows. Linux keeps paging in a separate partition and it would be really easy to use a small 4KB style SSD for paging then place your data on a 2TB disk using 8KB.
If Microsoft accepted the invite in 2003, 4KB could have been in the XP 64 bit edition and disk manufacturers would have jumped at it. Vista does not really count because few people wanted Vista. I helped a lot of people through the upgrade from Vista back to XP. That leaves Windows 7 as the first real upgrade since XP64. I think Microsoft dragged the chain just to force people on to Vista then the disk manufacturers delayed deployment because Vista fizzled out.
BIOS, chipset, and motherboard manufacturers are mushrooms with their head in the dark. They still offer floppy disk connections from 1970 and parallel printer connections from the 1950s when what we really need are ...
Oh well, with genetic engineering running riot, we will at least see pigs fly.
XP 64-bit had virtually no
XP 64-bit had virtually no users (nor an upgrade path from XP; it was all but irrelevant on the desktop), I truly doubt it would have made any converts amongst the disk vendors. The hardware people are a depressingly conservative bunch.
Vista sold at a faster rate than XP--to call it a fizzle is absurd, and seems to ignore XP's awful early days when Windows 98 users found that none of their hardware worked--and if Vista had had 5 years on the market with no successor I bet it'd have been more successful.
Frankly, I think the 2 TiB partition table limit is the only thing that's really motivated them to do anything, since they're facing the very real prospect of not being able to sell any disks larger than 2 TiB (a disk that around 95% of PCs can't partition is not an attractive proposition).
With EFI AWOL, vendors had two options: large sectors, or more godawful bootloader hacks to insert a load a EFI runtime from the first part of the disk and present the disk as a GPT to the OS, and who knows how well that would even work, but it sucks as an option anyway.
Large sectors was clearly the less painful option, especially as OS support is extant. That it alleviates ECC problems is just a bonus.
Oh, and it seems that it
Oh, and it seems that it wasn't until November 2003 that the disk vendors were in agreement (http://www.idema.org/_smartsite/external/bigsector/IDEMA_Long_Data_Block_WhitePaper_6_13_07.pdf); since XP 64 was based on Windows Server 2003, which was finished in April 2003. As such, I still think it's hard to blame MS for this one.
You are right
I knew XP64 was released in 2005 but did not know it was based on Windows Server 2003. I thought they just used XP, changed the compiler setting to 64 bit, and charged a lot of money.
I had XP running on some little old machines with 8Gb of memory and changed one to XP64. There was no document telling me the advantages of XP64. Speed was increased but not as much as adding a RAM disk to Windows 2000 then putting the page file on the RAM disk. If Microsoft had brought Microsoft RAID 1 from Windows Server across with the 64 bit code, XP64 would have been a killer on high end workstations.
Blame Seagate because back then they were the market leaders but were not leading the market where it really needed to go.
Great post! Thanks for the
Great post! Thanks for the information