Best Practice for EMC R22 （part3）

3．主机文件系统影响

在主机层次，通过指定最小最大的I/O request size，文件系统也影响了应用I/O的特性。

A.文件系统的缓冲和组合（coalesce）DOIT博客fbkNb

m.En/dx}%l2A A0跟在存储系统上的cache相似的是，缓冲是文件系统提高性能的一种主要方式。

缓冲DOIT博客8H5H&~/u1|
y
在大部分的情况下，文件系统的缓冲应该最大化，因为这能减少存储系统的负载。然而，还是会有一些意外。

一般来说，应用自己来调配缓冲，能避免文件系统的缓冲或者在文件系统的缓冲之外工作。这是基于应用能更加有效的分配缓冲的假设之上。而且，通过避免文件系统的coalesce，应用更能控制I/O的响应时间。但是，正如在64位的服务器里RAM的容量将会提升到32GB或者更多，这也就有可能把这个文件系统都放在缓冲里面。这就能使读操作在缓冲下，性能会有非常显著的提升。（写操作应该使用写透（write-through）的方式来达到数据的持续性。）DOIT博客:tG~N
O#mM0c

结合CoalescingDOIT博客%X,J%R)Ih b-s4oh#b
文件系统的coalesce能帮助我们从存储系统里获得更高的带宽。在大部分顺序访问的操作里面，用最大邻近和最大物理的文件系统设置来最大化文件系统的结合Coalescing.例如，这种处理方式可以和备份程序一起把64KB的写操作结合（coalesce）成一个完全stripe的写操作，这样在
;j~%t3T b'IJ4AHZ9@0write cache被bypass的情况下，对于带校验的Raid会更加有效果。DOIT博客 O6|S+Fk!v4y1pYH%R

5ALA%`5nu}(PE0B.最小化I/O的大小：文件系统的request size

'M6{sB'fL~"c!d0文件系统通常都被配置成一个最小的范围大小，例如4KB，8KB或者64KB，这是提供给阵列的最小的不可分割的请求。应用使用的I/O在比这个范围大小要小的时候，会导致很多不必要的数据迁移和/或read-modify-write的情形出现。这也是考虑应用和文件系统文件的最佳设置的最好办法。（it is best to consult application and file system documentation for the optimal settings）而request size没有被文件系统限制的Raw partitions，则没有受到这个约束。

c!S y ZBB,D0C.最大化的I/O大小

如果想要快速的移动大量的数据，那么一个大的I/O（64KB或更大）会更加有帮助。在整合（coalescing）顺序的写操作成Raid Group整个的stripe的时候，阵列将会更加有效率，正如预读取大的顺序读操作一样。大的I/O对从基于主机的stipe获得更好的带宽而言也是很重要的，因为他们将会被基于srtipe的toplogy打散成更小的大小。DOIT博客 P_^ CX

KT/ny,aZI0D.文件系统的fragmentation

避免fragmentation和defragementation在一起，这是一个基础的原则。注意NTFS文件系统可能被分区成任何形式除了默认的范围大小，他们不能被大部分的工具所defragement：这个API（程序的接口）并不能允许这样做。执行一个文件级别的拷贝（到另一个LUN或者执行一个文件系统的备份和恢复）是defragement的一个有效的实现。DOIT博客W{!["?%i+t`!^soh2S

Z rxQ IUQZ0DOIT博客!i;q(@;H2Q:d

跨越磁盘的小I/O在一些主机的类型里显得更加重要，而我们接下来将会探讨为什么会导致这种状况。

ie[lW;CP0当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响：
k&gFJPB{7S0a)有大比例的block size大于16KB的随机I/O
e}4E _i/l0b)Navisphere Analyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候（例如Exchange和Oracle），工作负载将会从对齐中获得一些优势。但因为I/O当中，小于6%（对于4KB）或者12%（对于8KB）的I/O都会造成跨盘操作（碰巧的是他们可能会以并行的方式来完成）。这种额外的收益可能很难在实践中注意到。但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移（offset）被注明，EMC推荐使用操作系统的磁盘管理来调整分区。Navisphere LUN的绑定位移（offset）工具应该要小心的使用，因为它可能反而会影响分层的应用同步速度。DOIT博客N:X2|{(?(qpR

NF4@"M6b1P6W7q0在Intel架构系统中的文件对齐DOIT博客R$N0BH:P&vUnq1h
Intel架构的系统，包括windows2000/windows2003，都会受到在LUN上元数据的位置的影响，这也会导致磁盘分区的不对齐。这是因为遗留的BIOS的代码问题，BIOS里面用的是磁柱，磁头和扇区地址来取代LBA地址。DOIT博客I6H \4A9D,YJ

FI.H:\o^7s S0（这个问题一样影响了使用intel架构的linux操作系统，正如windowsNT，2000，和2003。这个问题也一样影响了运行在intel硬件上的VMWare系统）

E E,Cu&LV9@(l0fdisk命令，正如windows的Disk Manager，把MBR（Master Boot Record）放在每一个SCDI设备上。MBA将会占用设备上的63个扇区。其余可访问的地址是紧接着这63个隐藏分区。这将会后续的数据结构跟CLARiiONRAID的stripe变得不对齐。DOIT博客 \X8I%Ld3M[

在linux系统上，这个隐藏扇区的多少取决于boot loader和/或磁盘管理软件，但63个扇区是一个最常遇到的情况。对于VMware，位移（offset）是63。DOIT博客$Vci*l$s"d)Sn!Q

在任何情况下，这个结果都为确定的比例的I/O而导致不对齐。大的I/O是最受影响的。例如，假设使用CLARiiON默认的stripe element 64KB，所有的64KB的I/O都会导致跨盘操作。对于那些比这个stripe element的小的I/O，会导致跨盘操作的I/O的比例，我们可以通过以下公式来计算：DOIT博客z!]E"H(O!y4FD{

1l9N+U|]0Percentage of data crossing=(I/O size)/(stripe element size)DOIT博客nIN5xfen"h

这个结果会给你一个大致的概念，在不对齐的时候的开销状况。当cache慢慢被填充的时候，这种开销会变得更大。DOIT博客W/x#Xcz7[3YW:n$^

%J9d)DC+~+v~0