前文再叙，书接上一回
文件系统的对齐
文件系统的不对齐会在以下两个方面影响性能：
1.不对齐造成了跨硬盘的访问：一个I/O跨越了两个硬盘（正常来说是只会访问到一个硬盘）
2.不对齐会让大的没有cache的写操作，变得难以条带对齐（strip-align）
第一个情形是更加容易碰到的。就算磁盘上的操作使用了cache的缓冲，也会对（性能）产生负面的影响，因为这会使cache的flushing变慢。随机的读操作（通过正常要求的磁盘访问产生的），也会受到相应的影响，不管是直接的（等待两个磁盘的响应以便返回数据）还是间接的（使磁盘的操作比正常更加忙）。
一个通常的例子如下图所示。基于intel架构的系统是不对齐的，这是因为元数据(Metadata)是被BIOS所写的。在一个对齐的系统，64KB的写操作会由单独一个硬盘来服务。
跨越磁盘的小I/O在一些主机的类型里显得更加重要，而我们接下来将会探讨为什么会导致这种状况。
当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响：
a)有大比例的block size大于16KB的随机I/O
b)Navisphere Analyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候（例如Exchange和Oracle），工作负载将会从对齐中获得一些优势。但因为I/O当中，小于6%（对于4KB）或者12%（对于8KB）的I/O都会造成跨盘操作（碰巧的是他们可能会以并行的方式来完成）。这种额外的收益可能很难在实践中注意到。但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移（offset）被注明，EMC推荐使用操作系统的磁盘管理来调整分区。Navisphere LUN的绑定位移（offset）工具应该要小心的使用，因为它可能反而会影响分层的应用同步速度。
在intel架构系统中的文件对齐
intel架构的系统，包括windows2000/windows2003，都会受到在LUN上元数据的位置的影响，这也会导致磁盘分区的不对齐。这是因为遗留的BIOS的代码问题，BIOS里面用的是磁柱，磁头和扇区地址来取代LBA地址。
（这个问题一样影响了使用intel架构的linux操作系统，正如windowsNT，2000，和2003。这个问题也一样影响了运行在intel硬件上的VMWare系统）
fdisk 命令，正如windows的Disk Manager，把MBR（Master Boot Record）放在每一个SCDI设备上。MBA将会占用设备上的63个扇区。其余可访问的地址是紧接着这63个隐藏分区。这将会后续的数据结构跟CLARiiONRAID的stripe变得不对齐。
在linux系统上，这个隐藏扇区的多少取决于boot loader和/或磁盘管理软件，但63个扇区是一个最常遇到的情况。对于VMware，位移（offset）是63。
在任何情况下，这个结果都为确定的比例的I/O而导致不对齐。大的I/O是最受影响的。例如，假设使用CLARiiON默认的stripe element 64KB，所有的64KB的I/O都会导致跨盘操作。对于那些比这个stripe element的小的I/O，会导致跨盘操作的I/O的比例，我们可以通过以下公式来计算：
Percentage of data crossing=(I/O size)/(stripe element size)
这个结果会给你一个大致的概念，在不对齐的时候的开销状况。当cache慢慢被填充的时候，这种开销会变得更大。
<未完待续>
