烦躁，网上说的没一个准的，烦了，设置成8k

res

板载的就算了吧，R5性能很无语

niub

这个其实很简单,大有大的好,小有小的好,自己权衡,老看别人的干什么

bcyj

原理上你说的没错，但是结论并不是必然的。举个极端的例子吧：
前提：4个硬盘组RAID 0，单盘性能：4k 200 IOPS/128k 100 IOPS，分别按照4k stripe size和 128k stripe size组成RAID 0
8K IOPS理论性能:4k stri ...
harleylg 发表于 2009-6-4 08:23

你以为每次访问文件都是从头访问到尾的(也就都是对齐的访问)?
你以为mft表里的内容也是全部对齐的?
你以为文件的附加权限控制也是对齐的?每个权限占一个簇?
你还是没有了解产生跨越的概率的问题,4k的stripe size,读写4k的数据,纯理论上,刚好位于一个簇里的机率是4k分之一.而按windows来说,实质上它都是按512(一个扇区)的大小来对齐读取的,那么刚好位于一个簇里的机率就是9分之一
4k stripe raid0: 200 × 4 / (4 * (1-0.11))=202 IOPS
128k stripe raid0:200 * 4 * ((256-16)/256)=744 IOPS

都说了很多次了,这个是一个理论概率问题,又拿什么8M的请求来说,如果一个请求大于stripe size的话,需要多盘响应的机率就是百分百了
就像大条带理论上的持续性能不如小条带的,但是由于卡上的预读缓存,实际上基本上没差别,而由于小条带占用卡的cpu比较高,有时候大条带持续更快.

最后,就是大的条带可以减低卡的运算量,让卡的运算能力不成为瓶颈.而预读缓存可以提高持续的性能,所以就在缓存大小和预读之间取个平衡,我第一个回帖那个公式就是根据实际测试结果来推导出来的比较合适日常家用的公式

yj2001

学习知识中.....

bcyj

学习了 ，
另外 如果是家用型主板的ICH7R以上做RAID5 HDTUNE 持续测试的时候图形跟山谷一样 很可怕 何解？

ICH9R和ICH10R上 用2003 EE和2008 STD都做过测试 结果是差不多的 条带为128K
winddomain 发表于 2009-6-4 09:35

因为ichx的raid5是软的raid5,用的是cpu做的xor运算,但是它要限制cpu的使用量,不可占用太多的时间片,同时他也没用大内存做缓存,所以就像山谷

拳头

弄点软件做对比测试啊，不过很多时候的应用不好模拟，还是IOMETER比较适合做这方面测试。

yphu

争论了这么久一个图都没有？

luckyps

标记一下。。看的晕了。。
先看看楼主头像 放松下

学步车

这才是技术探讨嘛，高深，默默路过

gz0921

这个帖子要留意下名了~~

harleylg

你以为每次访问文件都是从头访问到尾的(也就都是对齐的访问)?
你以为mft表里的内容也是全部对齐的?
你以为文件的附加权限控制也是对齐的?每个权限占一个簇?
你还是没有了解产生跨越的概率的问题,4k的stripe siz ...
bcyj 发表于 2009/6/4 12:00

恩，我的那个公式计算的确有问题，而且举的例子不对。

重新复习了一下，另外找了份评测的数据：

（来源：中关村在线，原文地址：http://memory.zol.com.cn/133/1332758.html
取其中希捷7200.12 1TB的测试数据。
假设4个硬盘组RAID0，Stripe Size取8K，那么4K时候的理论随机IOps：
1、按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上，7种情况在两个硬盘上，因此每个IO的实际物理响应IO数应该是（1×9+2×7）/16=1.4375，因此RAID0的4k随机IOps为70.34×4/1.4375=195.72
同样的道理，计算出来其他Stripe Size的IOps为
Stripe Size：8K__________32K_________128K_________512K
2K IOps:      236.93_______264.59______253.90________209.46
4k IOps:      195.73_______249.69______250.04________208.65
8K IOps:      145.22_______224.41______242.66________207.05

其他的也一样分析计算，可以看到就随机读取来说，并没有一个最优值，4K/8K的时候128K Stripe Size的性能最优，2K的时候是32K Stripe Size最优。更加不是你所说的越大越好，假设有支持512K Stripe Size的话。所以到底应该用多大的Stripe Size，还是要看实际的应用。

harleylg

补充一下：如果换成西数黑盘的话，4K的时候也是32K Stripe Size的IOps更高一点。具体计算我就不重复了。

bcyj

恩，我的那个公式计算的确有问题，而且举的例子不对。

重新复习了一下，另外找了份评测的数据：

（来源：中关村在线，原文地址：http://memory.zol. ...
harleylg 发表于 2009-6-5 15:06

你第一步就错了,"按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上"
512B对齐,Stripe Size=8K,那其实就是把一个Stripe Size分成 16块,读取8K的数据,就是读取16块,
两个盘的话,就是在32块里读取连续的16块,在不跨盘的情况就只有1-16和17-32这2种读取方式,其它的2-17,3-18直到16-31这14种都是跨越的了

harleylg

你第一步就错了,"按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上"
512B对齐,Stripe Size=8K,那其实就是把一个Stripe Size分成 16块,读取8K的数据,就是读取16块,
两个盘的话,就是在3 ...
bcyj 发表于 2009/6/5 16:10

8K Stripe Size,一共有16块512B，读取4K数据：
数据位置：1～8，2～9，3～10，……，9～16，一共9种情况在同一个盘上。10～17,11~18,……16～23，一共7种情况。MS我没有错吧？

bcyj

8K Stripe Size,一共有16块512B，读取4K数据：
数据位置：1～8，2～9，3～10，……，9～16，一共9种情况在同一个盘上。10～17,11~18,……16～23，一共7种情况。MS我没有错吧？
harleylg 发表于 2009-6-5 16:15

错了,如果是4k的话也错了1-8直到9-16,然后17-24直到25-32,18种

harleylg

错了,如果是4k的话也错了1-8直到9-16,然后17-24直到25-32,18种
bcyj 发表于 2009/6/5 16:31

呃，17～24跟1～8有什么不同么？
就算按照你的算法，两个8K Stripe也一共有32种对齐方式，18种在同一个硬盘上，跟我说的16种对齐方式，9种在同一个硬盘上有什么不同么？

bcyj

不同的,你的计算公式"（1×9+2×7）/16=1.4375"的错误在于把另一个盘的16块的双盘的机率计算了,但是没算那个盘的单盘的机率
简单说就是分母的不同,正确的应该是 1 + (7/(7+18))/2 = 1.14
验证如下
x为单盘iops,现在计算的是双盘
x * 2 * 18/25 + x * 7 / 25 = x * 2 / ( 1 + (7/(7+18))/2 )

harleylg

我又不是算一个盘的单/双盘几率，我算的是一个4K IO的物理IO几率……
就算按照你的方法算，4盘是8K×4/512B=64种对齐，
HDD1：1～8，2～9，……9～16
HDD2：17～24，18～25，……25～32
HDD3：33～40，34～41，……41～48
HDD4：49～56，50～57，……57～64
一共9×4=36种情况都是单盘，剩余28种情况都是双盘，
1×36/64+2×28/64=1.4375

你的算法问题在于你取了两个Stripe，一共有32种对齐情况，但你只取了这4K分布在这两个Stripe里面1～8，2～9，……，25～32一共25种情况。但事实上，如果是双盘RAID0的话，还有26～32+1，27～32+1～2，……，32+1～7这7种情况没算。三盘以上RAID0的话，那就是26～33，27～34，……，32～39。

难道说，这4K一定不会从26～32这7个位置开始？

bcyj

从26～32这7个位置开始,一样的,因为下一个区间又是第一个盘了,这个是单盘响应的机率