围绕4KB扇区硬盘，由于大家在这方面了解的基础不同。可能会有如下的疑问：
1、为什么会有4KB扇区硬盘?好处在哪里?2、原生4KB扇区和模拟512byte，兼容性有什么差别?3、4KB扇区对性能的影响4、软硬件生态系统，需要做哪些配合?5、SSD目前主要还是仿真磁盘块设备来使用，它是512byte还是4KB设备呢?6、在RAID阵列和虚拟机环境，硬件与Guest OS之间多了一个抽象层，这是否也会影响到4KB兼容?
以上6点相互关联，因此在本文中都会有所涉及。首先引起我们注意的是，近日有一份来自戴尔的资料，其中提到了2.5” 2TB 7.2K NLSAS(近线SAS)HDD的引入，这款硬盘采用的是512byte仿真扇区大小。
上表列出了3种硬盘扇区格式类型。512n——物理格式化和向主机呈现的逻辑扇区字节数均为512byte，早期的硬盘都是这样;512e——物理扇区大小为4096字节，逻辑上仿真为(8个)512字节扇区，为了兼容性的一种过渡;4Kn——即原生4KB，物理和逻辑扇区字节数都是4KB。
4KB扇区硬盘与生态系统概述
由于IT栈中的组件默认针对512b扇区大小已经30年了，下面我们来看看针对4KB扇区硬盘，整个生态系统需要分析/升级的地方。
服务器BIOS/UEFI – 支持4K可能需要UEFI – 传统BIOS需要修改来增加针对4KB原生驱动器的支持。
存储控制器(HBA)– 驱动和firmware需要改变。
RAID stack(位于RAID卡和阵列控制器)–驱动和firmware需要改变。
OS stack – 操作系统必须是4K感知才能使用4K原生驱动器;512e驱动器对于许多组件都支持，但是扇区对齐决定了获得最好性能。
文件系统 – 基于不同OS版本，这里可能有一些问题。微软对NTFS 做了一些改动，针对在Windows 7/2008 R2中支持512e。
应用 – 需要理解那些进行unbuffered(未缓冲)写入的应用。
Hypervisors – 512e可以被用于当前的微软/VMware hypervisors(性能可能变差)，但 VHD 1.0是硬性编码到512 byte并且没有当前的hypervisor支持4K原生 – 必须支持VHD 2.0规范来获得4K原生支持。
开发工具 – 分区对齐对于在512e 驱动器上达到最好性能是个关键。4K原生– 还没有数据来理解开发方面的问题。
什么是4KB高级格式化、路线图
如上图，原生512n每个扇区都有50bytes的ECC纠错码;4KB扇区将这个ECC区域合并、扩大(但没有50bytes的8倍那么大)，并省去了间隔、地址标记等空间，因此格式化效率提升到大约97%，并且能否检测和纠正更大的介质错误。
也就是说，在磁记录密度不变的情况下，“高级格式化”能够提供更大的实际可用容量。随着硬盘上的记录单元——磁极尺寸不断缩小，容量增速放缓，4KB扇区是未来大容量硬盘的趋势。
参考上图，512byte原生扇区硬盘的生命周期将在2017年终止(部分企业级产品和老型号可能例外)。按照这个之前的预计，以3.5” 7200转为例最大是4TB，超出该容量物理扇区只有4KB了?实际上我们看到有硬盘厂商推出6TB 512byte物理扇区的型号，包括密封充氦7碟片和非充氦普通6碟片，但继续增大容量还是需要4KB扇区。
4KB扇区仿真512byte已经广泛应用于客户端，毕竟即使出现写放大或者未对齐写入产生更多I/O，PC用户对磁盘性能也没有那么敏感，但企业级应用则要保守多了。除了4KB扇区仿真512byte，原生4KB扇区硬盘直到2014年晚期才发布针对企业级市场的版本，它无法工作在Windows Server 8(2012)之前的操作系统，并且与上文中我们介绍的生态系统密切相关。
这一段的几张截图来自IBM的一份文档，其中“Misaligned”和“Aligned”分别表示在使用512e硬盘时非对齐和对齐的4KB I/O块操作。由于4KB块(比如对应文件系统的页面)操作需要先以8个512bytes逻辑扇区写入到硬盘，再合并记录到4KB物理扇区，在非对齐的情况下，一个4KB逻辑写I/O对应到2个物理磁盘扇区，如果是新写入就会产生2次I/O;若是改写之前物理扇区中的数据，则需要读-更改-写的操作，这种非原子写入(non-atomic)最多可能产生4次I/O。
而对齐的情况则简单多了，尽管中间要经过硬盘模拟512bytes扇区的过程，但每个4KB的I/O操作都是对应到一个物理扇区。属于比较理想的情况。
我们参考下这个表格里不同操作系统对高级格式化的感知情况。其中，Windows从Server 2008开始能够感知512e硬盘并自动对齐分区;Server 2012进一步加入了对原生4Kn设备的支持。RHEL 6可以感知512e和4Kn硬盘并能自动对齐;SLES 11能感知512e和4Kn硬盘却无法自动对齐?VMware ESXi 4.x和5.x都无法感知512e和4Kn硬盘，但支持自动分区对齐。这里有必要进一步解释下。
首先对于Windows Server 2003、RHEL 5和SLES 10来说，512e硬盘首先是可以用的，只是操作系统“意识不到”而当成512n来用了。微软如今已经停止了对Server 2003的支持(戴尔等厂商为用户提供迁移方案和服务)，如果我们在这些较早的操作系统上使用第三方分区工具，或者手动指定开始扇区建立对齐的分区，应该可以规避一部分性能影响。
对于4Kn来说，这三款操作系统应该就没有办法兼容了，同样的还有VMware ESXi 4.x和5.x。尽管，VMware Hypervisor支持自动分区对齐(VMFS-3和VMFS-5分别以第128和2048为起始扇区)，但目前的ESXi 6.0和VSAN版本还是无法感知512e和4Kn，其中512e硬盘由于潜在性能问题而不被VMware官方支持。
上图截自VMware网站，供大家参考
这张图演示了在虚拟化环境下对齐和非对齐分区的情况。当“Aligned”对齐时，在Hypervisor层VMFS-5的文件块大小统一为1MB，子块(Sub-Blocks)大小8KB正好对应2个物理扇区上的16个逻辑扇区。此时如果虚拟机的OS block正好与VMFS子块对齐的话，等于就是与物理磁盘扇区对齐了，这样还算好一些的情况。
而对于“Misaligned”未对齐配置，如果要写入到虚拟机中的OS block 1，有2个VMFS子块被写入，并且每个子块需要2次读-修改-写周期(指改写而不是写入空白块，因为每半个VMFS block在“错位”情况下也会对应到2个物理扇区)。这样就有可能在底层产生8次I/O?
我们在VMware网站查询了更多关于4KB扇区兼容的情况，这方面应该还在遥远一些的Roadmap中。毕竟对于Hypervisor而言广泛的向后兼容性相当重要，512e我觉得将来会支持，而如果上层虚拟机就是要在4Kn硬盘上进行512byte的磁盘I/O，软件厂商没义务去做这个转换啊。
既然VMware如此，估计KVM和Xen的情况也不会好多少，对此我了解有限就不班门弄斧了。而Hyper-V可能是个特例吧，因为微软虚拟化平台上跑Windows虚拟机比较多，那么用VHD 2.0规范的4K原生磁盘格式运行Server 2012虚拟机应该不会出问题。
“对齐”并不代表性能就完全达到512n的水平，如果是小于4KB的随机写入512e硬盘还是会产生写放大或者惩罚。上面的软件兼容情况也适用于RAID卡和磁盘阵列的LUN，因为操作系统和虚拟机HyperVisor对它们是与本地磁盘同样的方式来看待。下面我们再来谈一下磁盘控制器对4KB扇区的兼容支持情况。
PERC卡和MD控制器的4KB扇区支持
如上图，左边是比较早的戴尔服务器SAS RAID卡、HBA、主板集成软RAID和MD家族阵列控制器。它们能够支持512e仿真扇区的硬盘，对于较早的操作系统可能需要补丁、对齐工具(比如让NTFS文件系统的簇与物理扇区对齐)和驱动更新。
对于这些传统磁盘控制器，对上层主机呈现的LUN(逻辑盘)都是512byte扇区。
到了新一代的PERC 9、MD38xx阵列控制器，以及未来的服务器软件RAID，已经能够支持原生4K扇区硬盘，并提供给主机4K格式的LUN。有同行朋友说这样做在一些场景下有性能的改善，也听到有专家说微乎其微。而我们想提醒大家的是：在选择这种“前卫”的配置之前，部分存储产品已经做好了准备，但上层软件兼容性需要用户自己注意，参考包括本文在内的资料，征询工程师/技术顾问的建议，必要情况下进行测试。
如上图，这台戴尔服务器配置了PERC 9系列RAID卡中的H730P Mini，它识别到当前选定SAS硬盘的物理和逻辑扇区大小都是512Byte。
组建RAID之后的虚拟逻辑盘(LUN)，自然也是512Byte扇区格式。当您阅读本文到这里，在此机器上如果换成512e或者4Kn的硬盘，会产生什么样的结果、有哪些注意事项就比较清楚了吧?
SSD的“扇区”是多大?
这里也要提一句SSD，据我们了解目前大多数的SAS/SATA SSD，在RAID卡和磁盘控制器管理程序中显示的物理和逻辑扇区大小都是512Byte，同样是兼容性考虑。其实闪存的最小写入单元——页面大小目前一般为4KB或者8KB，那么“扇区”也都是模拟出来的。测试反映这种模拟对性能的影响不大，因为FTL的存在，数据在SSD上的逻辑地址与物理闪存位置的对应关系都是可变的，来自主机小于4KB的写入也可能会合并到一个闪存页面上。
PCIe SSD(闪存卡)的情况不太一样，有些厂商在出货时“格式化”为4KB扇区，如果遇到软件应用不兼容的情况(比如Oracle数据库等)，可以使用专门的工具转换格式为512byte扇区大小。
当存储虚拟化网关遇上“4KB LUN”
从前端到后端都呈现4KB也许会在未来某个时候流行。而对于存储控制器而言，使用原生4KB扇区硬盘，却向上给主机呈现512byte的LUN单从技术实现上看却也可行，只要您不在乎性能打折扣——小于4KB的IO都会被放大至一个硬盘扇区，一次下发8个512byte写请求也可能会落到2个4KB扇区上(如果文件系统/应用层未对齐的话)。
这就是在控制器层面的“欺骗”，之前讲的512e是在硬盘层面上“欺骗”。
欺骗一词，用在这里并不是贬义。RAID技术本身就是将一组硬盘“虚拟化”为一块盘呈现给主机。由此我们还联想到被戏称为“上骗主机，下骗阵列”的存储虚拟化设备，它们与RAID控制器最大的不同就是其后端管理的存储单元由磁盘/SSD变成了阵列的LUN。
存储虚拟化对于后端阵列表现为“主机”，而在前端主机看来它又是一台“阵列”，基本原理可以简单解释为用Initiator导入LUN，再将其用Target导出给主机，中间可选加入数据服务。目前我们还没留意到有存储虚拟化产品宣称兼容4KB扇区格式的LUN?这一点在技术上实现估计并不是太难，关键取决于兼容性测试的工作量，以及实际的需求。
举例来说，一些存储虚拟化产品根据设置会在后端设备的LUN上再做一次条带化，以前都是按照512byte扇区来考虑，数据切块大小可以直接按一定数量扇区来计算就行。而如果扇区大小变成4KB，要是继续保持原有扇区数的话就意味着“条带”增大了8倍。对于导出给前端主机的LUN容量，也会存在类似的问题。
总结硬盘厂商对4KB扇区支持的动力毋庸置疑，但在逻辑上是否继续模拟512byte则取决于生态系统的进展。
对于企业存储而言，由于一些传统应用(如：Oracle数据库)的I/O操作最小单位仍小于4KB，使用原生512byte扇区硬盘可以保证最好的性能;模拟512byte能够兼容，但容易产生性能影响;至于原生4KB硬盘，则要求文件系统、卷管理器具备相应的支持，否则会报错。
目前一些比较新的服务器、磁盘阵列上的存储控制器，已经能够兼容原生4KB硬盘
