原来Advanced Format HDD已经普及了

​DBA对现代硬件的了解总是不足够的，虽然说有时候不了解这些东西，也不影响我们搞数据库运维。不过多了解一些这方面的知识总是好的。7、8年前我们刚刚开始使用SSD的时候遇到过4K扇区的问题，SSD盘分区的时候没有对齐性能会有影响。甚至弄得不好，存储在SSD盘上的Oracle Redo Log还会给你弄出点性能问题。

在一个朋友提出了一个Oracle 问题之前，我一直没有关注过目前普通机械盘是否也存在4K扇区的问题。直到前几天，一个朋友发了一个补丁，问512e是个啥意思。

这是一个Oracle 19C的BUG，在运行于RHEL/CENTOS 8的19.3的Oracle上，如果使用了ASMLIB，并且ASM磁盘组的磁盘包含512e的磁盘，则查询v$asm_disk的时候会出现CORE DUMP。而如果往这个磁盘组中添加磁盘的时候，甚至会导致整个磁盘组损坏。问题够吓人。

512e这个概念在数年前搞SSD盘的时候就大致了解过，学名叫512字节扇区仿真访问模式。在一些不支持原生态4K扇区的场景下，通过512字节的逻辑扇区来访问4K物理扇区的SSD设备也是以前经常用的方法。而这个BUG出现在HDD上，难道现在HDD也开始使用4K扇区了吗？于是我马上谷歌了一下，发现一种称为Advanced Format Hard Disk的磁盘技术在十多年前就已经开始出现了，而2014年后，大部分的硬盘企业都推出了企业级的AF硬盘。

关于4K扇区磁盘的好处，我在这里简单的讲一下，首先磁盘越来越大，4K盘可以在使用相同的寻址空间上获得更大的存储空间，另外一点，因为元数据的减少，也提高了磁盘容量的实际使用率，从硬盘厂商发布的数据看，使用4K扇区后，磁盘空间可用量多了7%以上。而从他们发布的性能数据上看，对于顺序读，顺序写的性能，采用4K扇区后都是有所提升的，随机读的性能略高（不知道这种略高是不是磁盘技术带来的，从转速和读取的性能上实际上是没有什么提升的），随机写的性能略有下降，不过几乎可以忽略。磁盘场厂商的数据告诉你，方向使用4K HDD吧，性能是没问题的。我咨询了一些国内的一些这方面的朋友，他们告诉我性能差异可以接受如果对齐边界，看不出明显的差别。不过不同的场景下，这些指标可能会有不同。只不过无论我们接受不接受，今后4K扇区的Advanced Format HDD肯定是标配了。

上面这个磁盘上面的红框中的LOGO就是4KN磁盘的标识。如果我们仔细查看一下自己手头的硬盘，应该可以发现存在这样的标识：

我们可以看到上面有两种LOGO，一种是512e的，另外一种是4Kn的，这是两种新的磁盘扇区访问的模式。AF是指本磁盘是4K一个扇区的，不过支持512逻辑扇区访问模式，操作系统可以把我当成512字节扇区的磁盘来访问。4Kn是指磁盘本身是4K扇区的，并且支持OS以4K本地访问的模式来访问这个磁盘。再加上原来的物理扇区就是512字节的磁盘，其访问模式称为512n，这三种磁盘访问模式就是我们日常能够遇到的HDD的访问模式。

于是我们的HDD世界中存在两种扇区规格，512和4K。为了向前兼容，4K扇区的磁盘也搞了一个512e的仿真访问模式，使原来的应用可以不做修改就能够访问4K扇区的磁盘。于是磁盘访问模式出现了3种：1）512n，其物理扇区和逻辑扇区都是512字节的，这是以前的传统访问模式；2）512e，其磁盘的物理扇区是4K的，不过为了兼容原有的系统，在分区的时候选择了512逻辑扇区大小；3）4Kn，其物理扇区与逻辑扇区都是4K的，系统采用原生4K的方式去访问这些磁盘。

Linux从RHEL/CENTOS 6开始支持原生的4Kn，之前都是通过512e的硬盘格式仿真访问。如果你采用4Kn的硬盘格式，那么是不需要考虑任何分区对齐之类的问题的。而如果你使用512e的方式，那么就必须认真考虑对齐的问题了。因为如果分区不做4K对齐，那么原本一个IO可以搞定的问题，就可能因为边界问题而要使用2个IO了，IO数量翻了一倍，对磁盘的压力也大了，IO延时也会增加。这对于数据库系统来说是十分不好的事情。

对于数据库来说，理解这些差异也是有用的。MySQL、PostgreSQL等数据库都是把数据放在文件系统上，IO也都是向Linux的文件系统发起，这些磁盘格式之间的差异被文件系统给屏蔽了，因此我们平时也不需要太关注这些。而如果你使用Oracle则有些不同了。

Oracle从11.2.0.3开始全面支持4K扇区磁盘，支持4Kn。Oracle的ASM是自己对IO进行优化的，为了达到极致，Oracle在Linux内核中增加了一个ASMLIB模块，用于和裸设备打交道。在普通情况下，Oracle通过512e的发格式访问磁盘扇区的数据，而在使用了ASMLIB的方式下，可以使用4Kn的模式访问磁盘，从而获得最佳的性能。

在创建磁盘组的时候，Oracle ASM的接口会自动获得逻辑扇区/物理扇区的大小，如果发现某个磁盘组内有不同的逻辑磁盘/物理磁盘大小的时候，就会报错。如果运气不好，遇到了本文开头提到的那个BUG，这时候还可能会引起DISKGROUP的故障（一般情况下不会，如果ASM实例设置了不理会逻辑扇区大小的参数_disk_sector_size_override，则大概率会出现此问题）。

在Oracle中使用4K扇区的磁盘，一定要注意几个方面：1）表空间的BLOCKSIZE不要低于4K,否则会面临性能问题，还好我们的绝大多数数据库都是用默认的8K BLOCKSZIE，不过某些超高并发，存在严重热块争用的系统往往会使用较小的BLOCKSIZE，也有一些客户为了避免热块冲突，把索引存放在2K BLOCKSIZE的表空间中；2）REDO LOG尽可能使用4Kn的磁盘格式，并且将REDO BLOCK大小设置为4K，而不是使用默认的512；3）创建磁盘组或者向磁盘组中加入新盘的时候，一定要检查物理扇区和逻辑扇区的大小，从而避免不兼容问题的出现。

最后要说的是，针对4Kn还是512e/512n模式，这是一个全链路问题。从磁盘到操作系统的任何一个环节上出现不一致的配置，或者不兼容的硬件，都会影响到我们最终获得的设备的属性。我在网上看到过一个案例。在同一台存储上分配的两个LUN，在操作系统层面看到的山区格式不同。

这种情况会导致创建ASM DISKGROUP的时候报错，在操作系统上检查了很久也没有发现问题，最终在存储上找到了原因。

在创建LUN的时候，同一个管理员在两个不同时间里创建的两个LUN使用了不同的BLOCK SIZE。存储管理员是不管这些的，他们也不知道这个参数还会引发Oracle的问题。

硬件发展虽然没有我们想象的那么快，只不过DBA的硬件知识更新的太慢了。以至于现代硬件数年前就已经研究的很清楚的问题，我们今天才去关注。如果不是那个Oracle的BUG，我可能还停留在HDD 512扇区的惯性里。这种知识的学习，什么时候是个头啊，选择DBA这个职业，真的得保持一颗学习的心。