今天参加了 EMC 组织的存储技术培训。因为频繁被电话打扰，导致听课效果并不是那么好。很多内容似曾相识，只是都断断续续的，几乎每次培训都是这样的，总有”断点”。

上午是 CLARiiON 的简单介绍，在模拟操作的时候我发现了以前漏掉的一个盲点：Binding LUN 的时候，那个 Alignment Offset 的选项到底是干啥的? 讲师简单说了一下，感觉不太对路子。刚才闲下来，查找了一下这个信息，大致搞明白了这个 ”Alignment offset“。

用 ”Alignment offset EMC“ 作关键字搜索到的第一篇文档是 Dell 工程师写的。这里面用了一个词 “signature block” , 莫名的一个词，我相信是 Dell 工程师自己发明的(用 Metadata 不就得了)。另外两个关键词是 “Windows” 和 “31.5KB” ，为啥是 31.5KB ，不知道。接下来在 EMC 的 Powerlink 网站上找到了比较详细的说明。

首先确定一下，这个问题更多是影响 Windows 系统。

老的 BIOS 代码，使用 ”柱面、磁头、扇区数“这一套机制而不是 LBA （Logical block addressing ）的模式来寻址。Linux 的 fdisk 工具还是 Windows 磁盘管理器，在每个格式化的设备上都放置一份 MBR 。这个 MBR 占用 63 个隐含扇区 (63*512=31.5KB, Bingo!)。这个问题在 Windows 上存在，在 VMware 上也存在，offset 同样是 63。 在有些 Linux 上，因为 Boot Loader 的不同，也会有类似的问题。

无视 Alignment offset 会导致的问题:

如图所示，一个 IO 会分裂到两个 Disk(Device/LUN) 上去，后果很严重。和我以前描述过的 4k Offset 问题本质上是一样的。只是这个是针对文件系统的。

那么，如何校正这个 ”对齐偏移量” 呢?

存储厂商的推荐是如果用 Snap View / SAN Copy 等存储级别的操作的话，不要折腾，用系统默认的就成，否则，用主机端的解决方案。

主机端的解决方案分为 Windows 32位、Windows 64 位、Linux、VMware 几种。

1） 对于 32 位的 Windows ，使用 Windows 系统资源包的 diskpar.exe 来设定 offset ( 据说 Windows 2003 SP1 上的 diskpart.exe 已经具备了 diskpar.exe 的功能。refer)

2）对于 64 位的 Windows ，GPT(GUID Partition Table)类型的分区默认有 32M 保留区，MBR 类型的分区自动校准。不存在这个问题。这就是 64位 的 Windows 众多优点之一啊。

3) 对于 Linux ，fdisk /dev/{devicename} 然后进入 expert 模式, 然后输入 b …

4) 对于 VMware，分为两种情况。虚拟机层（用虚拟机下操作系统的方案) 以及 ESX 服务器层 (fdisk).

上面几个步骤描述不详细，更详细的介绍你需要寻找一份白皮书： EMC CLARiion Best Practices for Fibre Channel Storage ，这个白皮书有针对 Flare 不同版本的，Flare 2.6 对这个问题有了比较好的改进。

是的，有的时候白皮书就在那里，只是没有人注意，没有看而已。

–EOF–