The problem, it seems from the article, is that is affects XP performance, but it is still usable.

To help Windows XP cope, advanced format drives will be able to pretend they still use sectors 512 bytes in size.

When reading data from a drive this emulation will go unnoticed. However, said Mr Burks, in some situations writing data could hit performance.

In some cases the drive will take two steps to write data rather than one and introduce a delay of about 5 milliseconds.

I'm not sure how much of an issue this is going to be, however. I'd think that as people upgrade their hardware they'd also upgrade their software.

Also I wonder if this sort of thing is patchable for XP?

I don't think it's patchable because this goes back to the NTFS awareness. I don't think you can go through the installation process. Besides, this is just another reason to force upgrades. XP is getting to be a dinosaur.

The new hard disk would almost certainly still be faster than the old one, so this isn't much of a problem. Also, I am doubtful that any loss of performance would result given that NTFS already works with 4KB clusters (1 cluster being 8 sectors). On an old hard disk, in theory, one cluster could be split over two tracks (requiring an extra step for a small read/write operation) but on one of the new hard disks a 4KB cluster would be guaranteed to exist entirely on a single track.

Kaled.

"All other things being equal you will have a noticeable hard drive reduction in performance," said Mr Burks, adding that, in some circumstances, it could make a drive 10% slower.

I don't know much systems running XP where the performance is disk bound and where a maximum performance hit of 10% would be noticeable.

IMHO the main problem is not with XP, but with server systems out there, either running on Linux with kernels from before September 2009 (i.e. all current mainstream distributions, maybe with the exception of Fedora which is often on the bleeding edge of technology) and all the Windows 2003 server type systems. These systems are often built to run a large number of years without OS upgrade, and my experience is that with growing amounts of data and fragmentation on the disks, most server systems end up to become disk-bound performance wise.

Maybe not quite so bad as it looks. Followup info from The Register:

[reghardware.co.uk...]

There is some nonsense here...

The smallest addressable storage unit when running any NT based operating system is 4KB (assuming the default cluster size is used when formatting and/or partitioning). Also, the only significant performance hit that might occur would be when paging virtual memory on and off the disk and guess what - the smallest unit of memory that can be mapped to disk is 4KB - I believe that is determined by the CPU architecture.

There's a myth factory at work somewhere - I wonder who's paying the bills. I also wonder why journalists that should know better are buying into this.

If anyone doubts this [support.microsoft.com...]
Scroll down to the section headed Default cluster sizes for NTFS

Kaled.

The problem is not cluster size vs. sector size, but the alignment of the two. If the 4K sectors on the disk aren't aligned with the 4K clusters of the file system, every write of one cluster will cause two writes in two separate sectors. It is the same with RAM memory. Although you can access every single byte in RAM individually, it is more efficient to align multi-byte memory objects like 32/64 bit integers or floats on 4 or 8 byte memory boundaries to improve read and write speeds.

The only thing I don't understand is why they are specifically addressing XP systems, because this problem is present with all file systems where clusters and sectors aren't properly aligned (i.e. all windows versions which were built before the 4K standard and all Linux versions below kernel revision 2.6.31).

The only reason that 4KB clusters might not be aligned on 4KB boundaries would be poor formatting - this would be trivial to patch. It would be no more difficult than using a maximum of seven sectors as padding for each partition.

This would not require any sort of operating system "awareness" when running - it's purely a formatting issue. Also, whilst I am not certain, I would be very surprised if existing formats failed to make the necessary alignment because dead space would be wasted at the end of the disk but could be used to store partition data at the start of the disk. If I had written a formatting program, clusters would definitely have been aligned.

Kaled.

What I like is the drive maker(s) are providing pin connectors to address the sector alignment...and/or are providing emulation software to address same. I don't see this as a non-starter. At this time, of course!

If I had written a formatting program, clusters would definitely have been aligned.

Then you may apply for a job at Microsoft. I just used Partition Manager to see where my NTFS partition on my Windows computer is located:

Partition 0, hard disk 0
File system: NTFS
Drive letter: C:
Sectors / boot: 8
Sectors / cluster: 8
Physical sectors:
First: 63 (Cyl 0, Hd 1, Sec 1)
Last: 73725119 (Cyl 4875, Hd 239, Sec 63)

The Windows system partition starts at sector 63, which is not at a 4K boundary. My system would therefore suffer from double sector writes if I would ever replace this disk with a new 4K version without realigning the partition.

The main problem is that NTFS is aligned at (virtual) heads and cylinders, not on sectors. My disk reports 63 sectors per cylinder with 240 heads and 5169 cylinders. I know that there are not 240 heads inside, but this kind of virtual addressing has become standard to avoid overflow of fixed maximum values in older BIOSes and operating systems.

Background on sectors/track
For perfomance reasons on older drive technology, the number of sectors per track has almost always been a prime number (17 on MFM for example), or some strange odd number involving a prime (63=7*9). The reason behind it was that with such a number you could easily play with the interleave factor of a disk (the number of rotations needed to read one track) to optimize disk read performance.

Interleave factors are something from the past, but it is difficult to weed out this kind of historical design criteria.

XP problems
FAT partitions have to be aligned on tracks, and NTFS followed this rule, upto and including Windows XP. Only with Vista, Microsoft stopped the mandatory cylinder alignment of partitions, causing XP systems using Vista formatted NTFS partitions to crash at startup. Microsoft has acknowledged this to be a problem and released KB931760 [support.microsoft.com] about this specific issue.

Cylinder-head-sector addressing hasn't been used for more than a decade. Logical block addressing was introduced to get past the 500MB barrier.

My system would therefore suffer from double sector writes if I would ever replace this disk with a new 4K version without realigning the partition.

If you used a sector-copying program to copy to the new hard disk, maybe, but would you really do that - I don't think so.

If you were to install a 4K drive, you would probably format it first (to check for errors) and then copy the files across. Maybe you would use a drive-imaging program that would do both. The point is this...

After being formatted correctly (i.e. aligning clusters on 4KB boundaries) XP will be able to use the drive optimally without any further modification to the operating system. To implement this would require only a tiny modification to a single DLL.

The main problem is that NTFS is aligned at (virtual) heads and cylinders, not on sectors. My disk reports 63 sectors per cylinder with 240 heads and 5169 cylinders.

If this is true, a 4K hard disk would merely have to report 32/64 sectors per track and everything would be fine - problem solved, absolutely no need to change anything in XP whatsoever.

Kaled.

Reporting a power of two for the number of sectors would make life a lot easier. Now with the standard LBA to CHS translation scheme LBA block 0 points to the first virtual track after the boot track, which happens to start at sector 63. Therefore every XP NTFS partition which has been located at the start of the disk just after the boot track is misaligned by design, not by accident.

The main problem of the current 63 value which is used by almost all disks is not with magnetic disks, but with SSD storage based on Flash. The default flash block size is often already 4K and by misalignment between the file system clusters and physical blocks you need two flash writes for every block write, reducing performance (writes are expensive operations on an SSD) and reducing the flash life time with 50%.