This may seem like a repeat of a thread from early 2010, but supposedly the fsutil in Win7 SP1 should be reflecting both logical and physical sector sizes. Indeed, it now has separate lines. However, my partition is showing 512-bytes for both. This is using Intel RST 10.1 hard disk controller driver, latest available.
I run “fsutil fsinfo ntfsinfo d:”
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Is the 10EARS supposed to show incorrect reading for the new ‘No, what is your sector size really???’ field? Or perhaps this data is stored in the filesystem, and would only be correct after a reformat in post-SP1? Getting the correct result is supposedly pretty important (see KB982018, available separately for SP0, and built-in to SP1, minus the improved fsutil which still needs the separate update)
AIUI, the drive reports its physical sector size via the ATA Identify Device command. CrystalDiskInfo is able to capture the 512 bytes returned by this command, in text format.
http://crystalmark.info/software/CrystalDiskInfo/index-e.html
The following thread may help:
http://community.wdc.com/t5/Desktop/WD20EARS-Windows-7-partitioning-and-formatting/m-p/181530#M5325
If I translate that to English, it sounds like I should find something in byte D4 and D5 of the 512-byte block.
4096-byte sector would probably read 60 03
512-byte sector would probably read 40 00
Mine reads 00 00
I wonder if Win7 SP1 truly is blind about the situation(no whitelist in ntfs.sys/storport.sys, etc.), and if so, does that mean the performance is reduced vs. if the drive reported fully.
I calculate the same hex values. Therefore, ISTM that Win 7 must assume the drive is non-AF. Nevertheless, Win 7 would still align the partitions on 4KB boundaries, and NTFS cluster sizes would remain at 4KB, or multiples thereof, so I don’t expect that performance would be negatively impacted. However, I have no personal experience with AF drives or Win 7, so there may be something I am missing.
My assumption is that performance will be reduced under certain conditions, otherwise the KB982018 update would not have been necessary to address certain performance issues.
I believe NTFS will still write only a single 512-byte sector, even if it knows the contents of the full 4k cluster. When it knows the physical is 4k, it would write a full 4k even if an app had only changed 512b. If this were not true, then Win7 SP1 would be sacrificing 512b write performance on non-AF drives. ISTM, the only way this isn’t the case, is if certain drives are hard-coded as AF drives in the driver code.
It appears that you are correct. The hotfix address several issues, including detection of AF drives via USB, adding AF reporting capability to several storage drivers, updates to the fsutil tool, and ensuring that the OS writes the full 4KB physical sector. Microsoft’s document stipulates that “this fix is dependent on the storage driver and the disk both reporting the correct physical sector size”. Since your AF drive does not appear to identify itself as such, ISTM that the benefits of the update are not available to you. 
An update that improves the compatibility of Windows 7 and Windows Server 2008 R2 with Advanced Format Disks:
http://support.microsoft.com/kb/982018
"Before Advanced Format disks were available, NTFS assumed that the logical sector size that was exposed by the disk interface was equal to the physical sector size of the disk. Although NTFS was originally designed to theoretically support larger sectors sizes, NTFS assumed that these two sector sizes were equal. When NTFS performs buffered writes at the end of a file in Windows 7 and Windows Server 2008 R2, NTFS pads the write operation to the end of the sector size which is exposed by the disk interface (the logical sector size). This behavior guarantees sector alignment. However, because the size of a logical sector of a 512e drive (“512-byte emulation disk”) is 512 bytes, the buffered write does not align to the physical sector size of the drive’s hard disk. This causes the Advanced Format disk to internally update the 512-byte logical sector within its 4KB physical sector, which can result in performance and reliability issues.
This hotfix introduces behavior to NTFS which makes sure that buffered writes at the end of the file are padded to the reported physical sector size of the disk."
