RAID0新玩法 三星840系SSD狂飙千兆/秒|全文浏览<span itemprop="datePublished" content="T05:54:00+-10-11 05:54&&&&【 原创】 作者： | 责编：孙玉亮&&&&&
两块新锐840系SSD组RAID0啥性能？&&& RAID0是有效提升速度的手段，其工作原理是将数据分别交由两块硬盘同时处理，因此读写速度提高接近100%。并且磁盘阵列系统的安装十分简单，只需要开启几个选项稍加设置，而后就和正常安装的步骤一样。那么两块最新的顶级组成磁盘阵列RAID0，速度究竟能有多迅猛？
RAID0新玩法 三星840系狂飙千兆/秒
&&& 机械硬盘全面推进到单碟时代，以希捷新酷鱼硬盘为例，其性能提高至少50%。不少网友选购两块希捷单碟，组成超大容量RADI0磁盘阵列系统，该系统的最大读写速度超过400MB/s，成本不过1000元。
&&& 单碟1TB硬盘组成的RAID0系统严重威胁，SSD同样可以采用RAID0模式，充分发挥SSD的性能优势，还可以保留两块SSD的容量空间。
&&&&SSD高不可及的时候，我们用64GB SSD组建RAID0，早期的SSD性能并不如现在那么惊艳，RAID0系统尚且发挥出令人难以置信的速度。当SSD发展到第三代，我们组建RAID0所用的SSD，单块容量升级到了容量，该系统的最大读取速度轻易突破1000MB/s，每秒进行的读写（I/O）操作次数高达16万次。
&&& 在本次测试中，我们将用最新发布的三星840系250GB固态硬盘组成的磁盘阵列RAID0系统，见证新的神奇双倍性能。 教程：BIOS中如何打开RAID模式教程：BIOS中如何打开RAID模式
　　用户构筑RAID 0阵列系列步骤非常简单，只需在BIOS中轻松几步设置即可搞定。
&&& 首先我们需要准备好两块相同容量的，连接在SATA3.0硬盘接口（SATAII接口速率已无法满足组RAID的速度需求），开机后按“DEL”键进入BIOS界面。笔者以技嘉Z77X-UD3H的BIOS设置为例：
主板BIOS界面中的SATA硬盘工作模式选项
&&& 我们进入“集成外设”(Peripherals)菜单后，将光标移动到“SATA模式选择”(SATA Mode Selection)选项，该选项是调节磁盘控制模式的，如上图包括IDE、RAID以及AHCI模式。
选择RAID模式后的BIOS界面
&&& 由于要组建，我们将选项调成RAID模式，然后回车确认。最后按F10保存退出，即可完成在BIOS重打开RAID模式。
教程：如何手动设置RAID参数教程：如何手动设置RAID参数
　　当BIOS保存重启后，会出现下图的画面“Press &CTRL+I& to enter Configuration Utility...”，你需要同时按下CTRL+I两个按键，即可进入RAID界面：
RAID界面提示信息
&&& 注：由于本次测试的三星840系 的速度快，我们还没来得及看到RAID提示界面就一闪而过，我们建议用户直接按&CTRL-I&，进入RAID界面；或者按“TAB键”以及“Pause Break”慢进。
　　上图为RAID菜单，其中设置界面中按“1”键是创建RAID磁盘，按“2”键是删除RAID磁盘，按“3”键是复位不需要组建的磁盘，按“6”键是退出。
组建RAID选项
&&& 上图为组建RAID的基本信息，
&&& 其中第一选项为RAID磁盘取名，一般选择默认即可。
&&& 在第二个选项中按左右选择RAID 0。
&&& 第三个选项按空格，选择你需要建立RAID 0的，这里笔者仅有两块硬盘，所以选项并没有激活，但如果你有三块或者以上的硬盘，则通过空格键选择需要组建RAID的磁盘。最后在选项Create Volume回车，并且按“Y”键保存。至此，你的2块硬盘已经组建成RAID 0，按Esc退出，重启。
组建成功的RAID信息
　　上图是已经组建好的RAID磁盘系统，接下来安装Windows 7笔者就不一一讲述了，方法和单块硬盘安装系统的步骤一样。
RAID 0阵列使用优缺点：
1、保持两块硬盘容量
2、获取至少195%的性能
3、设置和组建简单缺点：
1、暂时未能支持Trim功能，SSD持续使用较长时间后，速度出现衰减。
&& PS：机械硬盘无此问题。
2、无法使用Ghost软件备份镜像
&& PS：SSD安装系统超快，不亚于Ghost还原镜像文件。
注意事项：
1、最好组建RAID 0的两块硬盘容量、性能相同。2、组建好的RAID 0阵列的磁盘不可以将其中任意一块硬盘格式化或者分区，否则数据将全部消失。3、组建好RAID 0阵列的磁盘转换成别的RAID模式后，磁盘数据会丢失。反之两块无RAID模式的磁盘变为RAID 0阵列后同样数据会丢失。 Win7系统安装以及开机时间●Win7安装时间&
&&&&目前Windows7系统已经被用户所接受，所以大部分购买的机器或者装有Win7或者准备安装Win7，笔者使用Win7&64位旗舰版在系&/RAID0阵列系统进行安装，整个Win7安装过程从开机开始算起，结束时间以系统启动音乐时间结束为止。&
Win7安装界面
Win7自检容量
三星840系250GB&SSD/RAID0阵列系统安装Win7消耗时间
&&&&最终三星840系250GB&SSD/RAID0阵列系统安装完Win7，仅用4分43秒。它的安装速度不亚于Ghost还原镜像文件。
●&Win7开机时间对比&
　　在实际运用中，开机时间是大家关心的热门话题。在本次测试中，我们使用“开机助手”进行Win7系统开机时间计算。
单块三星840系250GB&SSD的的Win7开机时间
三星840系250GB&SSD/RAID0阵列系统的Win7开机时间
　　三星840系250GB&SSD/RAID0阵列系统的开机时间为14秒，对比单块的17秒开机时间，3秒的时间进步并不足以说明两块三星840系250GB&SSD组建RAID0阵列系统的性能。
&&&&的性能提升到一定阶段后，诸如开机时间的缩短空间不如机械硬盘过渡到SSD那么显著。
ATTO最大速度：读取直逼1100MB/秒● ATTO Disk Benchmark
　　ATTO Disk Benchmark是一款优秀且免费的磁盘基准测试软件，支持对稳定性/突发性传输速率进行读写测试，适用于常规、RAID、USB闪存盘、移动存储卡等的读写性能测试。
三星840系 的ATTO 队列深度4测试
　　单块三星840系250GB SSD在ATTO DiskBench 队列深度4测试中（默认），最大读取速度达到560MB/s，写入速度达到263MB/s。
三星840系250GB SSD/RAID0阵列系统的ATTO 队列深度4测试
　　两块三星840系250GB SSD组建RAID 0阵列系统后，相关测试的最大读取速度高达1086MB/秒，写入速度达到522MB/秒。
●ATT0队列深度测试
&&& ATTO Disk Benchmark的队列深度越大，相当于硬盘容量增加负载，三星840系250GB SSD/RAID0阵列系统的读写速度没有衰减。
　　三星840系250GB SSD/RAID0阵列系统在ATTO DiskBench 队列深度6测试中，最大读取速度达到1078MB/秒，写入速度达到516MB/秒。
三星840系250GB SSD/RAID0阵列系统的ATTO 队列深度8测试
　　三星840系250GB SSD/RAID0阵列系统在ATTO DiskBench 队列深度8测试中，最大读取速度达到1073MB/秒，写入速度达到522MB/秒。
三星840系250GB SSD/RAID0阵列系统的ATTO 队列深度10测试
　　三星840系250GB SSD/RAID0阵列系统在ATTO DiskBench 队列深度10测试中，最大读取速度达到1072MB/秒，写入速度达到520MB/秒。
&&& 小结：在ATT0 队列深度6、8、10的测试中，最大读写速度仅有小幅差距。
&&& 我们在测试中还发现细节问题：在ATTO 队列深度4测试中，两块SSD组成RADIO系统在“0.5-4字节”的读写速度无明显波动，到8字节的读写速度急剧飙升；随着队列深度增加到6-10区段，两块SSD组成的RAID0系统在16字节进入千兆/每秒的读取速度，它要之队列深度4延迟一个档次的字节。 CDM速度以及容量过载系数测试● CrystalDiskMark测试
　　CrystalDiskMark是一款简单易用的性能测试软件，但测试项目非常全面，涵盖连续读写、512K和4KB数据包随机读写性能，以及队列深度（Queue Depth）为32的情况下的4K随机性能。队列深度描述的是硬盘能够同时激活的最大IO值，队列深度越大，实际性能也会越高
三星840系 的CrystalDiskMark测试
　　从CrystalDiskMark测试看，三星840系250GB SSD的读取速度达到529.4MB/s，而写入速度也达到257.1MB/s。
三星840系250GB SSD/RAID0阵列系统的CrystalDiskMark测试
　　从CrystalDiskMark测试看，两块三星840系250GB SSD组建RAID 0阵列系统后，其持续读取速度突破1000MB/秒，而写入速度也达到512.8MB/秒。对比单块三星840系250GB SSD的性能提升幅度在95%以上。
●容量过载系数读写速度测试　　
&&& 由于采用闪存作为存储载体，不少网友担心固态硬盘出现类似优盘的掉速问题，即当硬盘的存储容量过载超过一定系数，读写速度出现衰减。我们将采用加载硬盘使用率的测试方法来验证它是否存在掉速问题。
　　下面就是三星840系250GB SSD/RAID0阵列系统在不同硬盘使用率下的CrystalDiskMark测试。笔者拷贝文件，将硬盘使用率分成34%、57%、81%、98%等三个阶段进行速度差异测试。
硬盘使用率34%
硬盘使用率57%
硬盘使用率81%
硬盘使用率98%
　　从上图中可以看到，三星840系250GB SSD/RAID0阵列系统从34%到98%这4个硬盘使用率阶段里，其读写速度相对比较稳定，其读取速度基本在1060MB/s－1064MB/s之间浮动，写入速度515MB/s－507MB/s之间浮动，并且4K字节、QD32队列深度的读写速度相当稳定。
&&& 我们综合评定三星840系250GB SSD/RAID0阵列系统无明显掉速现象，用户即使在接近满载容量的情况下，仍能保持高速读写性能。 HD Tune测试：平均读取速度超2倍
● 底层测试：HD Tune Pro v4.60
&&& HD Tune是一款性能诊断测试工具。它能检测硬盘的传输率、突发数据传输率、数据存取时间、 使用率、健康状态，温度及扫描磁盘表面等。另外，还可详细检测出硬盘的固件版本、序列号、容量、缓存大小以及当前的传送模式等。
三星840系 的HD Tune读取性能测试三星840系250GB SSD的HD Tune随机读取IOPS
三星840系250GB SSD/RAID0阵列系统的HD Tune读取速度测试
三星840系250GB SSD/RAID0阵列系统的HD Tune随机读取IOPS
&&&& 在HD Tune测试中，单块三星840系250GB SSD的平均读取速度只有419.7MB/秒；两块三星840系250GB SSD组建RAID 0阵列系统后的平均读取速度高达1003.8MB/秒，其读取速度走势相当稳定。
&&& 单块三星840系250GB SSD的4K随机IOPS值为10892，随机读取IOPS值为978。两块三星840系250GB SSD组建RAID 0阵列系统后的4K随机IOPS值为12379，随机读取IOPS值为1463。
&&& 小结：三星840系250GB SSD组建RAID 0阵列系统，其平均读取速度是单块的2.39倍速度。4KB、随机读取（IOPS）分别有13.6%和49.5%提升。 AS SSD测试：IOPS值高达16万● AS
　　AS SSD Benchmark是一个专门为SSD测试而设计的软件。可以测试出的持续读写性能，包括4KB小文件的传输性能等等，成绩显示可以分为两种，一种是MB/S的形式，另一种是IOPS形式。
三星840系 SSD的AS SSD读写测试
三星840系250GB SSD/RAID0阵列系统的AS SSD读写测试
　　在AS SSD测试中，单块三星840系250GB SSD在连续读取和写入方面达到了513.23MB/s和249.67MB/s。
　　两块三星840系250GB SSD组建RAID 0阵列系统后的连续读取和写入方面达到1002.66MB/s和502.95MB/s。
三星840系250GB SSD的AS SSD/IOPS测试
三星840系250GB SSD/RAID0阵列系统的AS SSD/IOPS测试
　 在4KB文件存取方面，三星840系250GB SSD的随机读取IOPS值为6724，随机写入为16566。其多线程读取/写入4KB文件的IOPS值为9，总分为938分。
&&& 两块三星840系250GB SSD组建RAID 0阵列系统后，其随机读取IOPS值为6410，而随机写入IOPS值为13338。其多线程读取/写入4KB文件的IOPS值为7516，总分为1644分。
&&&小结：三星840系250GB SSD/RAID0阵列系统的AS SSD读写速度和前面测试大同小异。在AS SSD的4K读写IOPS测试中，其读写IOPS值出现小幅倒退；4K多线程读写能力提升78.7%、106.8%。 随机读写性能/队列深度走势分析● Anvil's Storage Utilities测试
　　Anvil's Storage Utilities是一个专门为测试而设计的软件，它正在迅速成为最新的事实上的和标准检测程序之一，因为它提供了很大的可定制性。应用户要求，这项标准检测程序已经被添加到ServeTheHome的测试程序中。它提供类似 AS SSD Benchmark 测试结果汇总得分功能。
&&& 它的成绩显示可以分为两种，一种是MB/秒的形式，另一种是IOPS形式。本次测试我们将以黄色方框的读写速度以及红色方框的IOPS值为准。
Anvil's Storage Utilities测试（点击可放大）
&&& 在Anvil's Seq 4MB读写测试中，三星840系 SSD/RAID0阵列系统的读写速度分别为994.17MB/s和489.95MB/s。
&&& Iometer 4KQD16队列深度IOPS测试中，三星840系250GB SSD/RAID0阵列系统的读取IOPS值为82109.97、写入IOPS值为。
&&& 的每秒进行读写（I/O）操作的次数，与队列深度息息相关。随机读写性能强悍的SSD能够激活最大IO值，呈现队列深度越大，实际IOPS值也会越高。
&&& 在下面的测试，我们将Anvil's Storage Utilities软件进行Iometer测试，采用4K字节格式，记录和分析三星840系250GB SSD/RAID0阵列系统的随机读写性能/队列深度走势。
三星840系250GB SSD/RAID0阵列系统& 读取IOPS值/QD走势分析
&&& 三星840系250GB SSD/RAID0阵列系统在QD64队列深度基本达到读取IOPS值的上限，QD128略有增加。其中QD128时的读取IOPS值高达。
三星840系250GB SSD/RAID0阵列系统 写入IOPS值/QD走势分析
&&&& 三星840系250GB SSD/RAID0阵列系统在QD8队列深度基本达到写入IOPS值的上限，QD16/32/64逐步小幅提升，其中QD64时的写入IOPS值高达。
&&& 小结：三星840系250GB SSD/RAID0阵列系统的读取IOPS值在QD1-QD64之间跨度较大，在QD64-128之间处于高值浮动，其IOPS最高值超过17万，这样的数值是相当惊人的，是目前第二代主流SSD诸如美光M4的3倍以上数值。
&&&& 在写入IOPS值中，三星840系250GB SSD/RAID0阵列系统在QD8已处于高值，在QD16/32/64中则增长乏力。不过该系统的12万写入IOPS值足以笑傲群盘，期待满血的三星840PRO SSD创下新记录。 阵列双倍性能 Trim何时保全速度&&& 我们通过两款最新的顶级组件RAID0，无论是读写速度还是IOPS值，均有跨度较大的提升。RAID0阵列系统的一些缺点，随着机械过渡到SSD，缺点转化成为优点。比如城装机商喜欢采用Ghost安装系统，而现在顶级SSD组建的RAID0系统，它直接安装Win7系统的速度不亚于Ghost安装系统。
&&& Windows XP时代的不支持Trim功能，导致SSD使用时间长，无法回收垃圾文件，整体运行速度日渐缓慢。到了Win7时代，单块SSD已完美支持Trim功能，但是SSD组建RAID0系统却未能实现。
RAID0系统增挂从盘不影响阵列架构和性能
&&& 英特尔最先看到SSD磁盘阵列的商机，明年发布的8系列支持RAID模式下，将开启Trim功能，这项技术可以提高的性能，优化存储空间。SSD在RAID0和Trim技术的推动下，拉动双倍的SSD需求。
&&& RAID0阵列系统的最后一个缺点，也许是大家最关心的数据丢失问题，因为两块硬盘组成的RAID0系统，只要其中一块损坏，数据将全部丢失。面对这样的问题，我们该如何解决？
&&& 我们在多次组建RAID0阵列系统中摸索经验：RAID0系统可以挂从盘，并不影响RAID0阵列系统的组建。我们可以通过挂从盘的方式，将数据备份到从盘，避免RAIDO阵列系统损坏导致数据丢失。但是从盘怎么选择，却是大有学问。
Z77主板原生两个SATA3.0接口(白色）
&&& 1、以目前英特尔主流的6系列和7系列主板为例，原生SATA3.0接口默认只有两个，RAID0占用全部的两个SATA3.0接口。剩下4个接口为SATA2.0接口，如果我们选择主流的固态硬盘作为从盘，无法完全发挥固态硬盘的性能。
&&& 解决办法：购买第三方SATA.0芯片增加接口的主板，或者购买大容量的-3TB硬盘机械硬盘接驳SATA2.0接口。
&&& 2、8系、9系主板拥有至少6个SATA3.0接口，我们选购固态硬盘作为从盘没有后顾之忧，但是AMD平台组建RAID0性能不如英特尔平台。
&&& 那么有没有第3种选择，当然有，它还是英特尔的8系列主板，原生6个SATA3.0接口，第3种方案集合了方案1和2的优点。我们需要等到明年至少3月份该系列主板发布，届时第三代SSD已呈百家争鸣之势，我们可以从容选购SSD组建带有Trim功能的RAID0系统。 三星840系列250GB固态硬盘简介★三星840系列简介
&&& 三星840系250GB 保持830系列的整体黑色风格加上“一点红”特色，不过普及版840系SSD的外壳采用磨砂外壳，而830系采用抽丝工艺，后者看起来更为高贵。
三星840系250GB SSD
　　三星840系250GB SSD采用磨砂质感的全铝合金外壳，正面的外壳边框进行抛光处理，整体牢固，具有较强的抗压抗摔能力，同时金属外壳有利于散热。和纤细的830系SSD不一样，同为7毫米厚度的840系SSD外观看起来更结实。
三星840系250GB SSD的背面特写
通过标签我们可以清楚的看到这款固态硬盘的型号为MZ-7TD250，采用2.5英寸标准规格，容量为250GB，电压为1.7A，功耗大致为0.082-0.057瓦。
三星840系250GB SSD的接口特写
　　三星840系250GB SSD的传输接口为SATA3.0，接口速率为SATA 6Gbps，往下兼容SATA2.5/2.0/1.0接口。它的尺寸大小为100.2 x 69.85 x 7mm，适合用户、高端用户、企事业单位和工业领域。下面是该款SSD的拆解。 840系SSD拆解：高频三核+单面设计★840系拆解：高频三核+单面PCB设计
&&& 上一代830系SSD采用无螺丝的卡扣设计，不少用户反应830系SSD摔在地上之后，用手摇晃能听到PCB板和外壳碰撞的声音。三星根据客户反馈在840系SSD上做了相应改进，采用螺丝紧固设计。我们对三星2.5英寸830系512GB进行拆解分析，其内部三大核心部件的改进如下：
&& 1、主控频率提高和算法改进
&& 2、闪存带宽提高2倍以上
&& 3、缓存容量翻倍
三星840系 SSD拆解
三星840系250GB SSD的PCB正反面特写
在三星840系250GB SSD的内部PCB上，单面即可实现250GB容量，总计8颗32GB容量的三星原厂TLC闪存芯片和SATA I/O主控制芯片。并且配备一颗三星512MB 低电压缓存芯片。
三星S4LN021X01-8030 三核ARM主控芯片
　　主控方面采用三星研发生产的S4LN021X01-8030 MDX主控芯片，属于ARM架构的Cortex-R4系列三核，具备更强悍的多任务、多路数据读写传输能力。主要提高在算法设计和的频率，和830系的220MHz MCX三核主控相比，840系MDX主控的频率提高到300MHz。
三星840系250GB SSD的闪存芯片特写
　　闪存方面采用8颗21nm制造工艺的三星原厂的K9CFGY8U5A-CCK0 TLC闪存芯片，单颗芯片容量为32GB。其闪存采用先进的Toggle 2.0 NAND Flash技术，它的带宽提高到400Mbps，而上一代830系SSD则采用Toggle 1.1技术，闪存带宽仅133Mbps。
三星840系250GB SSD的缓存特写
&&& 缓存方面，它的PCB板正面搭载有一颗容量高达512MB DDR2低电压高速缓存芯片，为整个SSD的读写提供高速的数据缓冲。对比830系SSD仅256MB的缓存相比，840系SSD的缓存容量提高了一倍。
&&& 我们通过拆解三星840系250GB SSD，了解到这款SSD从主控、闪存、缓存均有三星生产，并且三个核心部件的规格均有一定幅度提高。 测试硬件与软件系统环境介绍 ● 测试硬件与软件系统环境介绍
　　本次测试采用英特尔22nm/ 3570K+技嘉Z77平台，其中Z77主板原生支持目前速率最快的原生SATA3.0 6Gbps接口。下面是具体平台介绍。
测 试 平 台 介 绍
（四核 / 100MHz*34 / 6MB共享L3缓存 ）
威刚极速飞龙 -2400套装
（ / DDR3-2400 / CL=7/单根）
技嘉GA-Z77X-UD3H
（Intel Z77 Chipset / BIOS版本号：F6）
镭风Xstorm HD6850
（Cayman Pro / 核心:775MHz / 显存:4000MHz / ）
三星840系列（普及版）X2
（三星S4LN021X01-8030主控制器 / SATA3.0 6Gbps）
（ATX12V 2.31 / 850W）
MAG GML2457
（24英寸LCD / 分辨率）● 测试系统的软件环境&
操 作 系 统 及 驱 动
Microsoft Windows 7 旗舰版
（中文版 / 版本号7600）
Intel Z77 Chipset fot Win7
（WHQL / 版本号 9.3.0.1019）
Catalyst 11.5 for Win7 旗舰版
（WHQL / 版本号 11.5）
● 测试软件介绍
HD Tune 5.00
ATTO Benchmark/CrystalDiskMark
Anvil's Storage Utilities
频道热词：&&&&&&
固态硬盘评测热点
排行 文章标题
TOP10周热门固态硬盘排行榜
商家报价：
105用户点评
商家报价：
105用户点评
商家报价：
35用户点评
商家报价：
105用户点评
商家报价：
商家报价：
31用户点评
商家报价：
139用户点评
商家报价：
商家报价：
49用户点评
商家报价：Super raid是什么？_百度知道
Super raid是什么？
我有更好的答案
磁盘阵列种用于提升硬盘速度数据安全性种技术
如果没有呢
没有就没有呗，不用这个功能就是了
其他类似问题
为您推荐：
raid的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁RAID阵列写入就出错，如何检查是硬盘问题还是卡问题？ - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
RAID阵列写入就出错，如何检查是硬盘问题还是卡问题？
17:09:49 +08:00 · 4748 次点击
系统是Debian 7.0.2 AMD64卡是LSI 9261-8i硬盘是Toshiba DT01ACA300 3T * 12组的RAID 6第一次组的时候，创建完阵列，还在后台初始化的时候，我就开始写入数据，当时有出错，阵列直接offline，重启的时候提示RAID卡内存错误。当时想说应该是还在初始化的时候我就写入数据导致的，所以就没理它，等到初始化完毕后才开始写入数据。然后2个礼拜前，再次要写入数据的时候，才开始写入没5分钟，阵列又offline了，这次直接联系RAID卡的卖家，让换了一个新卡(一换就是10天.....Orz)新卡拿来后，读取没问题，写入还是写入没几分钟就offline用smartctl -a /dev/sda -d sat+megaraid,{device id}命令进行检测，发现有4个硬盘有错误(刚忘了把日志拷贝出来...现在机器在运行磁盘检测看不到)把这4个硬盘拿出来用HDD Tune 5.5.0版本检查，只有C7 CRC接口错误(值为200，阀值也是200)阵列掉线时的日志如下[ 93.702174] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)[ 97.693024] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)[173.945570] megaraid_sas: wait adp restart[173.945577] megasas: moving cmd[0]:fffff8c0:0:ffff80 the defer queue as internal[173.945854] megasas: moving cmd[157]:fffff40:0:ffffc0 the defer queue as internal[173.945855] megasas: fwState=f0000000, stage:1[173.945876] megaraid_sas: FW detected to be in faultstate, restarting it...[174.947303] ADP_RESET_GEN2: HostDiag=a0[185.055067] RESET_GEN2: retry=0, hostdiag=a4[289.052430] RESET_GEN2: retry=3e8, hostdiag=a4[289.052434] megaraid_sas: FW restarted successfully,initiating next stage...[289.052435] megaraid_sas: HBA recovery state machine,state 2 starting...[319.171664] megasas: Waiting for FW to come to ready state[355.246848] sd 0:2:0:0: [sda] megasas: RESET cmd=2a retries=0[355.246852] megasas: HBA reset wait ...[361.214884] jbd2/sda1-8
2 0x[361.214889]
ffff8c0[361.214895]
3780 ffff8804284ebfd8 ffff8804284ebfd8 ffffc0[361.214899]
ffffe0 ffff[361.214904] Call Trace:[361.214919]
[&ffffffffa013e007&] ? jbd2_journal_commit_transaction+0x1a6/0x10bf [jbd2][361.214926]
[&ffffffff8100d02f&] ? load_TLS+0x7/0xa[361.214930]
[&ffffffff8100d69f&] ? __switch_to+0x133/0x258[361.214936]
[&ffffffff81039ac2&] ? finish_task_switch+0x88/0xb9[361.214940]
[&ffffffff81070fc1&] ? arch_local_irq_save+0x11/0x17[361.214946]
[&ffffffff8105fc83&] ? add_wait_queue+0x3c/0x3c[361.214951]
[&ffffffff&] ? _raw_spin_unlock_irqrestore+0xe/0xf[361.214958]
[&ffffffffa0142156&] ? kjournald2+0xc0/0x20a [jbd2][361.214962]
[&ffffffff8105fc83&] ? add_wait_queue+0x3c/0x3c[361.214969]
[&ffffffffa0142096&] ? commit_timeout+0x5/0x5 [jbd2][361.214973]
[&ffffffff&] ? kthread+0x76/0x7e[361.214978]
[&ffffffff&] ? kernel_thread_helper+0x4/0x10[361.214982]
[&ffffffff8105f5bb&] ? kthread_worker_fn+0x139/0x139[361.214986]
[&ffffffff&] ? gs_change+0x13/0x13[361.215227] ext4lazyinit
2 0x[361.215231]
ffff8c0[361.215236]
3780 ffff8 ffff8 ffff[361.215240]
ffffffff 6245 ffff8 fffffd0[361.215245] Call Trace:[361.215249]
[&ffffffff&] ? read_tsc+0x5/0x14[361.215252]
[&ffffffff&] ? io_schedule+0x59/0x71[361.215257]
[&ffffffff811995fe&] ? get_request_wait+0x105/0x18f[361.215261]
[&ffffffff8105fc83&] ? add_wait_queue+0x3c/0x3c[361.215266]
[&ffffffff&] ? blk_queue_bio+0x17f/0x28c[361.215270]
[&ffffffff8119908a&] ? generic_make_request+0x90/0xcf[361.215274]
[&ffffffff8119919c&] ? submit_bio+0xd3/0xf1[361.215279]
[&ffffffff81120e66&] ? bio_alloc_bioset+0x69/0xb6[361.215283]
[&ffffffff8119deb6&] ? blkdev_issue_zeroout+0xff/0x147[361.215293]
[&ffffffffa0150bb4&] ? ext4_init_inode_table+0x19d/0x241 [ext4][361.215297]
[&ffffffff8105263a&] ? del_timer_sync+0x34/0x3e[361.215301]
[&ffffffff&] ? should_resched+0x5/0x23[361.215313]
[&ffffffffa016525c&] ? ext4_lazyinit_thread+0xf3/0x228 [ext4][361.215323]
[&ffffffffa0165169&] ? ext4_register_li_request+0x207/0x207 [ext4][361.215328]
[&ffffffff&] ? kthread+0x76/0x7e[361.215332]
[&ffffffff&] ? kernel_thread_helper+0x4/0x10[361.215336]
[&ffffffff8105f5bb&] ? kthread_worker_fn+0x139/0x139[361.215340]
[&ffffffff&] ? gs_change+0x13/0x13[361.215585] flush-8:0
2 0x[361.215588]
ffffffff[361.215593]
3780 ffff8 ffff8 ffff0[361.215597]
ffff8 bb015d0 ffff80 fffffd0[361.215601] Call Trace:[361.215605]
[&ffffffff&] ? io_schedule+0x59/0x71[361.215609]
[&ffffffff811995fe&] ? get_request_wait+0x105/0x18f[361.215613]
[&ffffffff8105fc83&] ? add_wait_queue+0x3c/0x3c[361.215618]
[&ffffffff&] ? blk_queue_bio+0x17f/0x28c[361.215622]
[&ffffffff8119908a&] ? generic_make_request+0x90/0xcf[361.215627]
[&ffffffff811aea5b&] ? radix_tree_tag_set+0x64/0xbf[361.215631]
[&ffffffff8119919c&] ? submit_bio+0xd3/0xf1[361.215636]
[&ffffffff810bbc9a&] ? test_set_page_writeback+0xdc/0xeb[361.215644]
[&ffffffffa0156f5f&] ? ext4_io_submit+0x21/0x4a [ext4][361.215653]
[&ffffffffa0157185&] ? ext4_bio_write_page+0x1fd/0x3bc [ext4][361.215658]
[&ffffffff810b6994&] ? find_get_pages+0x82/0xd4[361.215667]
[&ffffffffa0153d86&] ? mpage_da_submit_io+0x2bd/0x36f [ext4][361.215676]
[&ffffffffa0155ad0&] ? mpage_da_map_and_submit+0x2e3/0x2f9 [ext4][361.215684]
[&ffffffffa0155dcd&] ? write_cache_pages_da+0x214/0x2c5 [ext4][361.215693]
[&ffffffffa0156120&] ? ext4_da_writepages+0x2a2/0x45d [ext4][361.215700]
[&ffffffff&] ? writeback_single_inode+0x11d/0x2cc[361.215704]
[&ffffffff&] ? writeback_sb_inodes+0x16b/0x204[361.215709]
[&ffffffff&] ? __writeback_inodes_wb+0x6d/0xab[361.215714]
[&ffffffff81118adf&] ? wb_writeback+0x128/0x21f[361.215717]
[&ffffffff81070fc1&] ? arch_local_irq_save+0x11/0x17[361.215722]
[&ffffffff81118f96&] ? wb_do_writeback+0x146/0x1a8[361.215727]
[&ffffffff8111907d&] ? bdi_writeback_thread+0x85/0x1e6[361.215731]
[&ffffffff81118ff8&] ? wb_do_writeback+0x1a8/0x1a8[361.215736]
[&ffffffff&] ? kthread+0x76/0x7e[361.215739]
[&ffffffff&] ? kernel_thread_helper+0x4/0x10[361.215744]
[&ffffffff8105f5bb&] ? kthread_worker_fn+0x139/0x139[361.215748]
[&ffffffff&] ? gs_change+0x13/0x13[361.215987] cp
00000[361.215991]
ffff88042a0faa70 0082 ffff ffffffff[361.215996]
3780 fffffd8 fffffd8 ffff88042a0faa70[361.216000]
ffff ffff[361.216004] Call Trace:[361.216010]
[&ffffffffa013c393&] ? start_this_handle+0x2ca/0x448 [jbd2][361.216014]
[&ffffffff8105fc83&] ? add_wait_queue+0x3c/0x3c[361.216020]
[&ffffffffa013c79c&] ? jbd2__journal_start+0x8a/0xce [jbd2][361.216028]
[&ffffffffa01538ce&] ? ext4_da_write_begin+0xd4/0x1be [ext4][361.216040]
[&ffffffffa016b6d8&] ? ext4_journal_start_sb+0x139/0x14f [ext4][361.216048]
[&ffffffffa01538ce&] ? ext4_da_write_begin+0xd4/0x1be [ext4][361.216056]
[&ffffffffa01557ac&] ? ext4_da_write_end+0x1f1/0x232 [ext4][361.216061]
[&ffffffff810b4f8b&] ? generic_file_buffered_write+0x10f/0x259[361.216067]
[&ffffffff810b5dc8&] ? __generic_file_aio_write+0x248/0x278[361.216071]
[&ffffffff8104b2ae&] ? current_fs_time+0x31/0x37[361.216075]
[&ffffffff&] ? should_resched+0x5/0x23[361.216079]
[&ffffffff810b5e55&] ? generic_file_aio_write+0x5d/0xb5[361.216087]
[&ffffffffa014ebd4&] ? ext4_file_write+0x1e1/0x235 [ext4][361.216092]
[&ffffffff810fa054&] ? do_sync_write+0xb4/0xec[361.216096]
[&ffffffff&] ? security_file_permission+0x16/0x2d[361.216100]
[&ffffffff810fa745&] ? vfs_write+0xa2/0xe9[361.216104]
[&ffffffff810fa922&] ? sys_write+0x45/0x6b[361.216108]
[&ffffffff&] ? system_call_fastpath+0x16/0x1b[535.962198] megasas: reset: Stopping HBA.[535.962362] sd 0:2:0:0: [sda] megasas: RESET cmd=2a retries=0[535.962510] sd 0:2:0:0: [sda] megasas: RESET cmd=2a retries=0[535.962656] sd 0:2:0:0: Device offlined - not ready after error recovery[535.963023] sd 0:2:0:0: Device offlined - not ready after error recovery[535.963030] sd 0:2:0:0: [sda] Unhandled error code[535.963032] sd 0:2:0:0: [sda]
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT[535.963036] sd 0:2:0:0: [sda] CDB: Write(10): 2a 00 00 be a8 00 00 01 00 00[535.967839] EXT4-fs warning (device sda1): ext4_end_bio:250: I/O error writing to inode
size 135168 starting block 1561888)[535.967996] sd 0:2:0:0: [sda] Unhandled error code
19 回复 &| &直到
08:00:00 +08:00
& & 17:36:08 +08:00
C7 都出错，LZ换数据线吧。
默默问一句：8i是怎么连12块硬盘的？
& & 18:03:21 +08:00
用的是24盘位的服务器机箱
C7错误我觉得应该是阵列出问题时导致的，因为我发现阵列offline的时候，都会有某个硬盘的灯在常亮
可能是刚好写入那个硬盘的时候offline，而且每次仅有一个会常亮。
& & 18:31:39 +08:00
@ 不是啊，9261-8i我怎么记得只能接8个硬盘呢？
还有LZ的硬盘使用环境怎样？
& & 18:36:30 +08:00
用megacli工具检查下看看
& & 19:07:29 +08:00
我的机箱是有带背板的，只要连接背板和RAID卡就可以让9261-8i带24个硬盘，甚至126个硬盘了(9261-8i官方说明，最高支持126个硬盘)
全套服务器都是新买的，才买来没2个礼拜就出这问题(加上换RAID卡的时间，就是一个月左右了)
从开始到出问题，也就写入5T左右的大数据(其实就是我之前下载的电影啦....)，而且是从其他硬盘拷贝资料到阵列里而已，然后就大概一个礼拜左右没去动它了（正常关机，断电）。即使是拷贝的时候，硬盘也保持在30度左右而已(机箱自带的8038风扇超给力，不过也超大声，像发动机一样)
offline的时候，用megacli工具检测会提示硬件不存在（类似，现在还在检查硬盘，用不了）
& & 20:20:12 +08:00
我感觉是有点像供电不足，12块盘瞬时电流也是很高的。
& & 23:30:38 +08:00 via iPhone
楼上说的有道理，看看你的背板最大能供多大的电流，除以12算一下能不能达到硬盘的规格
另外，RAID是可以一边初始化一边写入数据的
& & 01:07:26 +08:00
买的机箱是supermicro专门用来diy存储服务器用的机箱的，电源是机箱自带的1400W的冗余电源
& & 08:36:51 +08:00 via iPhone
尽可能升级RAID卡和硬盘的firmware到最新版本，排除兼容性的问题，不行的话，只能交叉验证硬件问题了
& & 11:24:47 +08:00
RAID卡的固件已经是升级到最新版本了，硬盘倒是没升级，因为想说出厂日期都是今年10月份，应该都是最新的，等会看看
& & 15:27:39 +08:00
@ 另外用 @ 提到的megacli看一下phy error count, 可以看到是不是信号完整性的问题
megacli -PhyErrorCounters -a0
& & 17:06:43 +08:00
应该也不是信号完整性的问题哦
我刚开始以为是驱动问题，因为Debian 7我没安装RAID卡驱动，装完系统自动识别到，所以我就没再安装（官方提供的驱动也只说支持Debian 603）
但早上安装了Windows 2008 R2测试，RAID卡的驱动也是LSI官方最新的驱动，也是一写入数据就马上offline
offline的时候，MegaRAID Storage Manager软件里连RAID卡都看不到了，所以这应该不可能是硬盘问题吧？？如果是硬盘问题，应该最多就是某个阵列掉线吧？？
C:\Users\Administrator&megacli -phyerrorcounters -a0
Adapter #0
================
Phy No: 0
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 1
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 2
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 3
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 4
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 5
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 6
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Phy No: 7
Invalid DWord Count
: 0
Running Disparity Error Count : 0
Loss of DWord Synch Count
: 0
Phy Reset problem Count
Exit Code: 0x00
& & 17:32:19 +08:00
话说有什么办法可以一次检查多块硬盘是否有问题吗？
因为这都是第二块RAID卡了，难道真的那么倒霉连续碰到2块有问题的卡？？
& & 22:39:51 +08:00 via iPhone
@ 对了，你的系统是带expander的，所以你这边看到的是RAID卡到expander的情况，要看expander后面的HDD情况还得找找看是什么参数
& & 22:43:52 +08:00 via iPhone
RAID卡不见了是因为driver侦测到有错误reset HBA了，这个信息从上面Debian的系统log里面可以看到
& & 22:57:03 +08:00
expander是LSI-SAS2X36
Enclosure 1:
Number of Slots
Number of Power Supplies
Number of Fans
Number of Temperature Sensors : 1
Number of Alarms
Number of SIM Modules
Number of Physical Drives
Connector Name
: Port 0 - 3
Enclosure type
FRU Part Number
Enclosure Serial Number
ESM Serial Number
Enclosure Zoning Mode
Partner Device Id
Inquiry data
Vendor Identification
Product Identification
Product Revision Level
Vendor Specific
: x36-55.14.18.0
& & 23:00:59 +08:00
话说在Windows下检测出C7警告的硬盘，在Linux下用smartctl检测则是出现这个错误信息
这信息是啥意思？？
SMART Error Log Version: 1
ATA Error Count: 2
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It &wraps& after 49.710 days.
Error 2 occurred at disk power-on lifetime: 72 hours (3 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
84 51 95 6b 4e 04 04
Error: ICRC, ABRT at LBA = 0x04044e6b =
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC
Powered_Up_Time
Command/Feature_Name
-- -- -- -- -- -- -- --
----------------
--------------------
61 00 00 00 4e 04 40 00
00:14:39.085
WRITE FPDMA QUEUED
61 00 00 00 4d 04 40 00
00:14:39.084
WRITE FPDMA QUEUED
61 00 00 00 47 04 40 00
00:14:39.082
WRITE FPDMA QUEUED
61 00 28 00 4c 04 40 00
00:14:39.078
WRITE FPDMA QUEUED
61 00 20 00 4b 04 40 00
00:14:39.078
WRITE FPDMA QUEUED
Error 1 occurred at disk power-on lifetime: 10 hours (0 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
84 51 d3 2d d8 5c 09
Error: ICRC, ABRT at LBA = 0x095cd82d =
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC
Powered_Up_Time
Command/Feature_Name
-- -- -- -- -- -- -- --
----------------
--------------------
61 00 00 00 d8 5c 40 00
01:05:23.837
WRITE FPDMA QUEUED
61 00 00 00 d7 5c 40 00
01:05:23.836
WRITE FPDMA QUEUED
61 00 00 00 d6 5c 40 00
01:05:23.835
WRITE FPDMA QUEUED
61 00 00 00 d5 5c 40 00
01:05:23.834
WRITE FPDMA QUEUED
61 00 00 00 d4 5c 40 00
01:05:23.833
WRITE FPDMA QUEUED
& & 16:20:38 +08:00
出现smart error应该是硬盘的可能性比较大了, 试着把有问题的盘低格一下, 如果还不行的话就节哀吧-_-!!
& & 16:43:27 +08:00
但是这个错误是RAID卡出错时导致的哦
我原本硬盘smartctl检查都没问题的，然后RAID卡出错的时候，必定有一块硬盘的灯是常量的，然后再用smartctl检查的话，那块硬盘就会出现那个错误，放到WIN里用HD TUNE检查的话，就是C7错误
我昨天尝试把所有硬盘都一一接到主板的SATA接口上，然后检查坏道什么的，也尝试格式化后写入读取测试，都没问题
现在再次把RAID卡寄回去保修了，之前换的那个没问说到底卡有没有问题，这次寄回去有要求给答复
& · & 1606 人在线 & 最高记录 1847 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.7.3 · 52ms · UTC 08:39 · PVG 16:39 · LAX 01:39 · JFK 04:39? Do have faith in what you're doing.}