如何测试云硬盘

问题
UOS公有云开放以来，一些用户反应用dd命令测试出来的1TB云硬盘的吞吐率(MBPS)只有128MB/s，而不是我们SLA保证的170MB /s ，这是为什么？下面我会简单介绍如何测试硬盘，RAID，SAN，SSD，云硬盘等，然后再来回答上面的问题。
测试前提
我们在进行测试时，都会分清楚:
测试对象：要区分硬盘、SSD、RAID、SAN、云硬盘等，因为它们有不同的特点
测试指标：IOPS和MBPS(吞吐率)，下面会具体阐述
测试工具：Linux下常用Fio、dd工具, Windows下常用IOMeter,
测试参数: IO大小，寻址空间，队列深度，读写模式，随机/顺序模式
测试方法：也就是测试步骤。
测试是为了对比，所以需要定性和定量。在宣布自己的测试结果时，需要说明这次测试的工具、参数、方法，以便于比较。
存储系统模型
为了更好的测试，我们需要先了解存储系统，块存储系统本质是一个排队模型，我们可以拿银行作为比喻。还记得你去银行办事时的流程吗？
去前台取单号
等待排在你之前的人办完业务
轮到你去某个柜台
柜台职员帮你办完手续1
柜台职员帮你办完手续2
柜台职员帮你办完手续3
办完业务，从柜台离开
如何评估银行的效率呢：
服务时间 = 手续1 + 手续2 + 手续3
响应时间 = 服务时间 + 等待时间
性能 = 单位时间内处理业务数量
那银行如何提高效率呢:
增加柜台数
降低服务时间
因此，排队系统或存储系统的优化方法是
增加并行度
降低服务时间
硬盘测试
硬盘原理
我们应该如何测试SATA/SAS硬盘呢？首先需要了解磁盘的构造，并了解磁盘的工作方式：
每个硬盘都有一个磁头(相当于银行的柜台)，硬盘的工作方式是：
收到IO请求，得到地址和数据大小
移动磁头(寻址)
找到相应的磁道(寻址)
读取数据
传输数据
则磁盘的随机IO服务时间:
服务时间 = 寻道时间 + 旋转时间 + 传输时间
对于10000转速的SATA硬盘来说，一般寻道时间是7 ms，旋转时间是3 ms, 64KB的传输时间是 08 ms， 则SATA硬盘每秒可以进行随机IO *** 作是 1000/(7 + 3 + 08) = 93，所以我们估算SATA硬盘64KB随机写的IOPS是93。一般的硬盘厂商都会标明顺序读写的MBPS。
我们在列出IOPS时，需要说明IO大小，寻址空间，读写模式，顺序/随机，队列深度。我们一般常用的IO大小是4KB，这是因为文件系统常用的块大小是4KB。
使用dd测试硬盘
虽然硬盘的性能是可以估算出来的，但是怎么才能让应用获得这些性能呢？对于测试工具来说，就是如何得到IOPS和MBPS峰值。我们先用dd测试一下SATA硬盘的MBPS(吞吐量)。
#dd if=/dev/zero of=/dev/sdd bs=4k count=300000 oflag=direct
记录了300000+0 的读入 记录了300000+0 的写出 1228800000字节(12 GB)已复制，17958 秒，684 MB/秒
#iostat -x sdd 5 10

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 000 000 000 1679480 000 13435840 800 079 005 005 7882

为什么这块硬盘的MBPS只有68MB/s 这是因为磁盘利用率是78%，没有到达95%以上，还有部分时间是空闲的。当dd在前一个IO响应之后，在准备发起下一个IO时，SATA硬盘是空闲的。那么如何才能提高利用率，让磁盘不空闲呢？只有一个办法，那就是增加硬盘的队列深度。相对于CPU来说，硬盘属于慢速设备，所有 *** 作系统会有给每个硬盘分配一个专门的队列用于缓冲IO请求。
队列深度
什么是磁盘的队列深度？
在某个时刻,有N个inflight的IO请求,包括在队列中的IO请求、磁盘正在处理的IO请求。N就是队列深度。
加大硬盘队列深度就是让硬盘不断工作，减少硬盘的空闲时间。
加大队列深度 -> 提高利用率 -> 获得IOPS和MBPS峰值 -> 注意响应时间在可接受的范围内
增加队列深度的办法有很多
使用异步IO，同时发起多个IO请求，相当于队列中有多个IO请求
多线程发起同步IO请求，相当于队列中有多个IO请求
增大应用IO大小，到达底层之后，会变成多个IO请求，相当于队列中有多个IO请求 队列深度增加了。
队列深度增加了，IO在队列的等待时间也会增加，导致IO响应时间变大，这需要权衡。让我们通过增加IO大小来增加dd的队列深度，看有没有效果：
dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct
记录了1000+0 的读入 记录了1000+0 的写出 2097152000字节(21 GB)已复制，106663 秒，197 MB/秒
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 000 000 000 38060 000 38973440 102400 239 628 256 9742
可以看到2MB的IO到达底层之后，会变成多个512KB的IO，平均队列长度为239，这个硬盘的利用率是97%，MBPS达到了197MB/s。(为什么会变成512KB的IO，你可以去使用Google去查一下内核参数 max_sectors_kb的意义和使用方法 )
也就是说增加队列深度，是可以测试出硬盘的峰值的。
使用fio测试硬盘
现在，我们来测试下SATA硬盘的4KB随机写的IOPS。因为我的环境是Linux，所以我使用FIO来测试。
$fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb \
-name="EBS 4K randwrite test" -iodepth=64 -runtime=60
简单介绍fio的参数
ioengine: 负载引擎，我们一般使用libaio，发起异步IO请求。
bs: IO大小
direct: 直写，绕过 *** 作系统Cache。因为我们测试的是硬盘，而不是 *** 作系统的Cache，所以设置为1。
rw: 读写模式，有顺序写write、顺序读read、随机写randwrite、随机读randread等。
size: 寻址空间，IO会落在 [0, size)这个区间的硬盘空间上。这是一个可以影响IOPS的参数。一般设置为硬盘的大小。
filename: 测试对象
iodepth: 队列深度，只有使用libaio时才有意义。这是一个可以影响IOPS的参数。
runtime: 测试时长
下面我们做两次测试，分别 iodepth = 1和iodepth = 4的情况。下面是iodepth = 1的测试结果。
上图中蓝色方框里面的是测出的IOPS 230, 绿色方框里面是每个IO请求的平均响应时间，大约是43ms。方框表示95%的IO请求的响应时间是小于等于 9920 ms。橙色方框表示该硬盘的利用率已经达到了9858%。
下面是 iodepth = 4 的测试:
我们发现这次测试的IOPS没有提高，反而IO平均响应时间变大了，是17ms。
为什么这里提高队列深度没有作用呢，原因当队列深度为1时，硬盘的利用率已经达到了98%，说明硬盘已经没有多少空闲时间可以压榨了。而且响应时间为 4ms。 对于SATA硬盘，当增加队列深度时，并不会增加IOPS，只会增加响应时间。这是因为硬盘只有一个磁头，并行度是1， 所以当IO请求队列变长时，每个IO请求的等待时间都会变长，导致响应时间也变长。
这是以前用IOMeter测试一块SATA硬盘的4K随机写性能，可以看到IOPS不会随着队列深度的增加而增加，反而是平均响应时间在倍增。
队列深度 IOPS 平均响应时间
1 332931525 3002217
2 333985074 5986528
4 332594653 12025060
8 336568012 23766359
16 329785606 48513477
32 332054590 96353934
64 331041063 193200815
128 331309109 385163111
256 327442963 774401781
寻址空间对IOPS的影响
我们继续测试SATA硬盘，前面我们提到寻址空间参数也会对IOPS产生影响，下面我们就测试当size=1GB时的情况。
我们发现，当设置size=1GB时，IOPS会显著提高到568，IO平均响应时间会降到7ms(队列深度为4)。这是因为当寻址空间为1GB时，磁头需要移动的距离变小了，每次IO请求的服务时间就降低了，这就是空间局部性原理。假如我们测试的RAID卡或者是磁盘阵列(SAN)，它们可能会用Cache把这1GB的数据全部缓存，极大降低了IO请求的服务时间(内存的写 *** 作比硬盘的写 *** 作快很1000倍)。所以设置寻址空间为1GB的意义不大，因为我们是要测试硬盘的全盘性能，而不是Cache的性能。
硬盘优化
硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟)：
提高转速(降低旋转时间和传输时间)
增加Cache(降低写延迟，但不会提高IOPS)
提高单磁道密度(变相提高传输时间)
RAID测试
RAID0/RAID5/RAID6的多块磁盘可以同时服务，其实就是提高并行度，这样极大提高了性能(相当于银行有多个柜台)。
以前测试过12块RAID0，100GB的寻址空间，4KB随机写，逐步提高队列深度，IOPS会提高，因为它有12块磁盘(12个磁头同时工作)，并行度是12。
队列深度 IOPS 平均响应时间
1 1215995842 0820917
2 4657061317 0428420
4 5369326970 0744060
8 5377387303 1486629
16 5487911660 2914048
32 5470972663 5846616
64 5520234015 11585251
128 5542739816 23085843
256 5513994611 46401606
RAID卡厂商优化的方法也是降低服务时间：
使用大内存Cache
使用IO处理器，降低XOR *** 作的延迟。
使用更大带宽的硬盘接口

SAN测试
对于低端磁盘阵列，使用单机IOmeter就可以测试出它的IOPS和MBPS的峰值，但是对于高端磁盘阵列，就需要多机并行测试才能得到IOPS和MBPS的峰值(IOmeter支持多机并行测试)。下图是纪念照。
磁盘阵列厂商通过以下手段降低服务时间：
更快的存储网络，比如FC和IB，延时更低。
读写Cache。写数据到Cache之后就马上返回，不需要落盘。 而且磁盘阵列有更多的控制器和硬盘，大大提高了并行度。
现在的存储厂商会找SPC帮忙测试自己的磁盘阵列产品(或全闪存阵列)， 并给SPC支付费用，这就是赤裸裸的标准垄断。国内也有做存储系统测试的，假如你要测试磁盘阵列，可以找NSTC (广告时间)。
SSD测试
SSD的延时很低，并行度很高(多个nand块同时工作)，缺点是寿命和GC造成的响应时间不稳定。
推荐用IOMeter进行测试，使用大队列深度，并进行长时间测试，这样可以测试出SSD的真实性能。
下图是storagereview对一些SSD硬盘做的4KB随机写的长时间测试，可以看出有些SSD硬盘的最大响应时间很不稳定，会飙高到几百ms，这是不可接受的。
云硬盘测试
我们通过两方面来提高云硬盘的性能的：
降低延迟(使用SSD，使用万兆网络，优化代码，减少瓶颈)
提高并行度(数据分片，同时使用整个集群的所有SSD)
在Linux下测试云硬盘
在Linux下，你可以使用FIO来测试
*** 作系统：Ubuntu 1404
CPU： 2
Memory: 2GB
云硬盘大小： 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )
安装fio：
#sudo apt-get install fio
再次介绍一下FIO的测试参数：
ioengine: 负载引擎，我们一般使用libaio，发起异步IO请求。
bs: IO大小
direct: 直写，绕过 *** 作系统Cache。因为我们测试的是硬盘，而不是 *** 作系统的Cache，所以设置为1。
rw: 读写模式，有顺序写write、顺序读read、随机写randwrite、随机读randread等。
size: 寻址空间，IO会落在 [0, size)这个区间的硬盘空间上。这是一个可以影响IOPS的参数。一般设置为硬盘的大小。
filename: 测试对象
iodepth: 队列深度，只有使用libaio时才有意义。这是一个可以影响IOPS的参数。
runtime: 测试时长
4K随机写测试
我们首先进行4K随机写测试，测试参数和测试结果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb \
-name="EBS 4KB randwrite test" -iodepth=32 -runtime=60
蓝色方框表示IOPS是5900，在正常的误差范围内。绿色方框表示IO请求的平均响应时间为542ms， 方框表示95%的IO请求的响应时间是小于等于 624 ms的。
4K随机读测试
我们再来进行4K随机读测试，测试参数和测试结果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb \
-name="EBS 4KB randread test" -iodepth=8 -runtime=60
512KB顺序写测试
最后我们来测试512KB顺序写，看看云硬盘的最大MBPS(吞吐率)是多少，测试参数和测试结果如下所示：
#fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb \
-name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60

蓝色方框表示MBPS为174226KB/s，约为170MB/s。
使用dd测试吞吐率
其实使用dd命令也可以测试出170MB/s的吞吐率，不过需要设置一下内核参数，详细介绍在 128MB/s VS 170MB/s 章节中。
在Windows下测试云硬盘
在Windows下，我们一般使用IOMeter测试磁盘的性能，IOMeter不仅功能强大，而且很专业，是测试磁盘性能的首选工具。
IOMeter是图形化界面(浓浓的MFC框架的味道)，非常方便 *** 作，下面我将使用IOMeter测试我们UOS上1TB的云硬盘。
*** 作系统：Window Server 2012 R2 64
CPU： 4
Memory: 8GB
云硬盘大小： 1TB
当你把云硬盘挂载到Windows主机之后，你还需要在windows *** 作系统里面设置硬盘为联机状态。
4K随机写测试
打开IOMeter(你需要先下载)，你会看到IOMeter的主界面。在右边，你回发现4个worker(数量和CPU个数相同)，因为我们现在只需要1个worker，所以你需要把其他3个worker移除掉。

现在让我们来测试硬盘的4K随机写，我们选择好硬盘(Red Hat VirtIO 0001)，设置寻址空间(Maximum Disk Size)为50GB(每个硬盘扇区大小是512B，所以一共是 50102410241024/512 = 104857600)，设置队列深度(Outstanding I/Os)为64。
然后在测试集中选择”4KiB ALIGNED; 0% Read; 100% random(4KB对齐，100%随机写 *** 作)” 测试
然后设置测试时间，我们设置测试时长为60秒，测试之前的预热时间为10秒(IOMeter会发起负载，但是不统计这段时间的结果)。
在最后测试之前，你可以设置查看实时结果，设置实时结果的更新频率是5秒钟。最后点击绿色旗子开始测试。
在测试过程中，我们可以看到实时的测试结果，当前的IOPS是6042，平均IO请求响应时间是1056ms，这个测试还需要跑38秒，这个测试轮回只有这个测试。
我们可以看到IOMeter自动化程度很高，极大解放测试人员的劳动力，而且可以导出CSV格式的测试结果。
顺序读写测试
我们再按照上面的步骤，进行了顺序读/写测试。下面是测试结果：
IO大小 读写模式 队列深度 MBPS
顺序写吞吐测试 512KB 顺序写 64 16407 MB/s
顺序读吞吐测试 256KB 顺序读 64 17932 MB/s
云硬盘的响应时间
当前云硬盘写 *** 作的主要延迟是
网络传输
多副本，写三份(数据强一致性)
三份数据都落盘(数据持久化)之后，才返回
IO处理逻辑
我们当前主要是优化IO处理逻辑，并没有去优化2和3，这是因为我们是把用户数据的安全性放在第一位。
128MB/s VS 170MB/s
回到最开始的问题 “为什么使用dd命令测试云硬盘只有128MB/s”， 这是因为目前云硬盘在处理超大IO请求时的延迟比SSD高(我们会不断进行优化)，现在我们有两种方法来获得更高的MBPS：
设置max_sectors_kb为256 (系统默认为512)，降低延迟
使用fio来测试，加大队列深度
通过设置max_sectors_kb这个参数，使用dd也可以测出170MB/s的吞吐量
root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb
512
root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb
root@ustack:~#
root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct
40+0 records in
40+0 records out
1342177280 bytes (13 GB) copied, 751685 s, 179 MB/s
root@ustack:~#
同时查看IO请求的延迟：
root@ustack:~# iostat -x vdb 5 100

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vdb 000 000 000 68800 000 17612800 51200 5459 9347 000 9347 140 9656
下面是使用fio工具的测试结果，也可以得到170MB/s的吞吐率。
不可测试的指标
IOPS和MBPS是用户可以使用工具测试的指标，云硬盘还有一些用户不可测量的指标
数据一致性
数据持久性
数据可用性
这些指标我们只能通过根据系统架构和约束条件计算得到，然后转告给用户。这些指标衡量着公有云厂商的良心，有机会会专门进行介绍。
总结
上面介绍了一下测试工具和一些观点，希望对你有所帮助。
测试需要定性和定量
了解存储模型可以帮助你更好的进行测试
增加队列深度可以有效测试出IOPS和MBPS的峰值

比如一般来说，读写时，读写灯闪烁，硬盘坏，红灯常亮，

每个公司的产品亮灯机制都是不一样的。但是读写和坏的状态都一样，

闪红灯，如果频率是1HZ或者4HZ都是有意义的。

比如下面的机制就是一款服务器的闪灯机制。你的R710肯定也有自己的闪灯机制，但是一般来说都比较类似。

C5出现，意味着你的硬盘正在向着坏道发展。
C7一般没事。
下面详细解释一下：
一、
重新映射扇区是这样的，其实现在的硬盘真实容量和标称容量是不一样的，比如你买的是1T，但是实际上可能是12T。一旦某个扇区出问题了，硬盘自己的固件会将这个扇区加入P-list或者是G-list，然后会从多出的02t中找一个扇区代替那个坏的，这就是重新映射扇区。
这某种程度上也就是服务器硬盘和普通硬盘的区别，服务器的备用空间更多，这种机制也更加完善。
这相当于球场的候补队员。当场上队员受伤时，可以替换，所以虽然有队员受伤，但并不影响比赛。
重新映射扇区，就是为了避免数据损失而采取的候补队员机制。在备用的映射扇区足够的时候，并不影响数据安全。
但是，如果场上队员不断受伤，候补队员总有用完的时候；同理，备用映射扇区也总用完的时候。一旦用完，你就硬盘就该出现物理坏道了。而且，通常坏道的面积会不断扩大。
所以，有少量的重映射扇区也属正常，不影响数据安全。你用Hdtune测试，看健康度，如果重映射扇区的数据在迅速加大，那说明坏的扇区在不断扩散，备用扇区总有一天会用光，到时候就会出现坏道了，你的数据就危险了。
所谓物理维修硬盘的软件只能暂时延长使用期限，用不了多久还是会坏的。现在只是有点卡，将来会丢数据。所以，你应该赶紧备份数据，然后可以接着用，用到受不了卡顿的时候就处理掉这块硬盘吧。
二、 Ultra DMA CRC错误计数
“Ultra DMA CRC错误计数”(C7)没有非常具体的解释，一般来说表示这个是硬盘接口有所损坏，一般硬盘正常多次插拔，都会有这个报警，不过别担心，请仔细查看主板的SATA接口和硬盘SATA接口，是否有明显磨损或者烧毁痕迹，如果没有这些迹象，硬盘可以安全使用，换多几个版本HD-TUNE软件进行测试，就会发现有的HD-TUNE有告警，有的没有。
代码一般是C7，但不同的厂家对这个代码的定义不同，用通用软件，比如hdtune测C7错误，不一定就是UDC错误。

硬盘响是怎么回事？自己能修复吗？
硬盘声音大，硬盘声音主要是咯咯咯的清响，质量不好的硬盘会声音比较恭，还有就是如果硬盘碎片过多也会加大硬盘工作量从而声音更大，还有一种情况就是硬盘出现坏道了，也会导致硬盘声音加大，扫描一下就行了，整理碎片要做一下，顺便说一句，BT等下载工具下载文件会产生大量磁盘碎片，解决方法是每当下载完成以后，将已经下载的进行转存，存到另一个分区。

不行就格式化修复一下，再不行低格。
硬盘录像机总是报警怎么回事，提示硬盘错误，，，
可能硬盘坏了。

可以先进入菜单，用超级管理员（admin）用户进去，试着格式化一下这块硬盘。格式化完成后重启硬盘录像机。看是否正常。如果还提示硬盘错误，可以把这块硬盘拆下来，接到电脑上格式化一次，再装上试试，如果还不行，那你就得换一块硬盘。
部分录像机里面有一个地方需要设置硬盘数量，这个地方的数量要和实际的硬盘数量相符，如果不相符也会报警。

参考资料：

安防专家 yhvideo
硬盘出现警告怎么回事？ 5分
你的重新映射扇区不要紧，数字不大。涉及重新映射扇区的代码有三个：05、C4和C5，表示不同的含义：

一、

(05)重新映射扇区是这样的，其实现在的硬盘真实容量和标称容量是不一样的，比如你买的是1T，但是实际上可能是12T。一旦某个扇区出问题了，硬盘自己的固件会将这个扇区加入P-list或者是G-list，然后会从多出的02t中找一个扇区代替那个坏的，这就是重新映射扇区。

这某种程度上也就是服务器硬盘和普通硬盘的区别，服务器的备用空间更多，这种机制也更加完善。

这相当于球场的候补队员。当场上队员受伤时，可以替换，所以虽然有队员受伤，但并不影响比赛。

重新映射扇区，就是为了避免数据损失而采取的候补队员机制。在备用的映射扇区足够的时候，并不影响数据安全。

但是，如果场上队员不断受伤，候补队员总有用完的时候；同理，备用映射扇区也总用完的时候。一旦用完，你就硬盘就该出现物理坏道了。而且，通常坏道的面积会不断扩大。

所以，有少量的重映射扇区也属正常，不影响数据安全，它本身就是硬盘的自我修复的机制。但你要用Hdtune测试，看健康度，如果重映射扇区的数据在迅速加大，那说明坏的扇区在不断扩散，备用扇区总有一天会用光，到时候就会出现坏道了，你的数据就危险了。

如果你硬盘用了两三年，有少量的重映射扇区，那也是正常的。备份一下重要数据，继续用吧，用到哪天有大量坏道出现或觉得卡得受不了，处理掉再买一块硬盘好了。

(C4)重新映射事件计数表明了做扇区重映射的尝试总次数。成功的转移和不成功的转移都会被计数。

(C5) 当前待映射扇区计数 Current Pending Sector Count (应小于阈值)

“不稳定的”扇区数量，即等待被映射的扇区数量。 如果不稳定的扇区随后被读写成功，这个值会降低，扇区也不会重新映射。扇区读取错误不会造成重新映射，扇区只会在写入失败时发生重新映射。这个值有时候会 有问题，因为带缓存写入不会重新映射扇区，只有直接读写才会真正写入磁盘。假如这个数值异常，则可能预示硬盘快挂了。。。。

二、 Ultra DMA CRC错误计数

“Ultra DMA CRC错误计数”(C7)没有非常具体的解释，一般来说表示这个是硬盘接口有所损坏，一般硬盘正常多次插拔，都会有这个报警，不过别担心，请仔细查看主板的SATA接口和硬盘SATA接口，是否有明显磨损或者烧毁痕迹，如果没有这些迹象，硬盘可以安全使用，换多几个版本HD-TUNE软件进行测试，就会发现有的HD-TUNE有告警，有的没有。

代码一般是C7，但不同的厂家对这个代码的定义不同，用通用软件，比如hdtune测C7错误，不一定就是UDC错误。

另外，如果是SSD出此错误，不必在意。因为SSD的 art定义与机械盘不同。新盘也经常会测出这个错误。没事。
硬盘检测告警是怎么回事 5分
这些警告说明了硬盘的重映射扇区已经有了数据

正常情况下硬盘在工作时可能会产生损坏或不可读写的区块，为了使这部分地址可以正常使用，硬盘中会专门划分出一个区域，把那些不正常的地址映射到这个区域中，用这个正常的区域代替那些损坏的地址。当硬盘读写到那些不正常区块时就直接跳到这个区域的对应位置进行读写。

只要这个区域已经有了映射数据，软件就会显示出警告，一般都属正常，但当这个区域容量满的时候，软件就会报“红”，说明硬盘已经没有重映射空间，今后再出现不正常的区块时也没有正常地址可以代替了，建议备份数据更换硬盘，以保证今后数据的可靠性。

一般情况下，只要重映射扇区的数值增加很慢的话，是没有什么问题的，但如果每个月甚至每天都有增加的话，这就不正常了，请检查一下硬盘数据线是否接触不良，电源是否正常等等。必要的时候换一条好的数据线，好的D形头电源线，或更换一个功率足够的品牌电源等等。

而你的情况已经是到了晚期，只能返修了。
电脑硬盘一直响，请问是怎么回事
这种情况一般硬盘本身没有什么问题，通常是软件方面造成的。比如程序或服务的后台运行，或者是病毒木马在后台捣乱。数据碎片也会造成磁头的频繁寻道，畅出咕噜咕噜声。只要不是咔咔响你就尽可以放心。

建议杀毒，整理碎片，清理后台运行的程序或服务即可减轻该状况。
监控硬盘机报警是怎么回事
可能是图像丢失，硬盘错误。硬盘满所造成的，你检查一下录像机异常处理里面那样选择的是什么报警。
硬盘响是怎么回事？
一片硬盘好比“一盒鸡蛋”

易碎的内部组件

即使外壳看起来完好无损， 内部组件也可能被损坏

轻巧便携

一个鸡蛋（组件）坏了会导致整盒鸡蛋（硬盘）拒收; 只有装鸡蛋的盒子能轻易地打开并检查里面的物品

这个简单比喻以一盒鸡蛋——日常的东西作比，以便那些接触硬盘的人能更好地理解。

虽然外表坚固，但硬盘的内部组件如同盒里的鸡蛋，两者都很可能由于不正确的 *** 作而受损

一、硬盘损坏类型：

1、磁头撞击/鸣响

2、磁盘刮伤

3、马达噪音 /振动

4、污染物

5、磁头损坏

6、电路板刮伤

7、电路组件损坏

8、连接器外壳损坏

9、连接针弯曲二、用户能看（感觉）到的损坏

1、间歇性的功能问题

2、写的问题

3、读的问题

4、运行慢

5、永久性的数据丢失

6、硬盘不通电

7、噪音过多

三、注意：

很多损坏 *** 作员经常是看不到的，因为失败可能会出现在几分钟、几小时、几天、甚至是损坏的几个月后。

损坏可能是由于人为的撞击、工具同电路板的接触、连接器的不正确插入等原因造成的。

1．未通电的硬盘上磁头可能会从磁盘上擡起并撞上盘体导致磁性材料和/或磁头的损坏。（称为“磁头撞击”）

2．磁盘可能会放射状地滑动

3．导致偏位

4．磁头就不

5．能正确地读到数据

6．磁头臂可能没有锁住磁头导致其从磁盘的一边滑向另一边

7．刮伤了磁性材料

8．连接端口或电源接口的不正确嵌入或移出会使连接器外壳断裂或连接针弯曲
硬盘异响是怎么回事··
硬盘运行中除了马达声以外，还会有“咔咔”的读数声（声音不很低沉），这属于正常现象；

但是，如果发出低沉的“嗒嗒”声，就说明硬盘有物理性损坏，或工作条件不佳；

1、物理性损坏说明硬盘已经或者接近报废；

2、工作条件不佳，是指它的这种故障现象并不能说明硬盘有问题，而是它的数据传输、电源供应等方面出现问题；

例如，如果主机电源的滤波电容失效或漏电，就会导致硬盘发出“嗒嗒”的异响；

因此，楼主要分辨出这种异响是属于什么情况，即什么“异响”，才好判断硬盘是否存在问题。
电脑提示硬盘故障怎么办 每次开机都提示
一、可能是硬盘接口接触不良，或硬盘连接线有问题，或硬盘出现坏道。将硬盘连接线拔下来，清除上面的灰尘和硬盘的灰尘后再插回去，一定要插紧。如果紶硬盘连接线有问题，换根新的用。

二、检测硬盘是否有坏道，若有，修复一下，一般说来也可解决问题。

到dell的支持网站，下载open manage光盘，然后安装，这样就可以在浏览器里详细看到服务器的所有相关信息。

3块硬盘除了，R5，还可以做R1，剩下的一块做热备盘，在有一个硬盘失效的情况下，会自动重建而不需要人工干预，但是这样空间的浪费太大了。

1、更高的稳定性和可靠性。服务器硬盘因为通常是全天24小时不间断的运行，工作量非常巨大，应词各大厂商为了保证服务器硬盘的质量，都会采用各种先进的速度加入硬盘中，来保证数据的安全稳定，为了防止各种意外带来的损失，服务器硬盘通常可以承受300G到1000G左右的冲击力。

2、支持热插拔。目前市面上的服务器硬盘都支持热插拔，热插拔也是服务器硬盘的安装方式，因为服务器通常是不会停机的，因此每当服务器硬盘拔出或者插入时， *** 作系统都会自动识别变动的硬盘，这对于不间断工作的服务器来说是必须的，如果对于不是那么关键业务，也可以选择重启更换硬盘，因为热插拔还是有一定数据损伤的。

3、硬盘转速快。服务器的硬盘转速比较快，通常可以达到7200转、10000转甚至更高的转速，同时它还配备了回写是缓存，平均访问时间比较比较短，我不传输速率与美妙传输速率都比较短，子啊性能上比普通硬盘要出色不少。

4、使用SCSI硬盘接口。因为服务器的吞吐量比较大，CPU运行的程序较多，通常会使用SCSI接口的硬盘，SCSI接口的硬盘在外部与内部传输速率都比较高，性能非常出众，但是SCSI硬盘必须通过SCSI接口才能使用，目前市面上的服务器硬盘采用主流的Ultra320SCSI标准接口，有些专用的SCSI可以7个设备，这是普通硬盘不能相比的。

以上就是我给大家介绍的服务器硬盘特点，相信大家对此有了一定的了解，希望能帮到大家。

    数据是服务器最核心的内容，而储存数据的硬盘则是服务器的灵魂，其他硬件出现故障问题不大，硬盘出现故障却是灾难级别，是致命的故障，如果硬盘的数据丢失，那么之前的努力将会前功尽弃。不管服务器配置有多高，硬盘有多新，多么先进，都会有出现故障的几率；因此在使用服务器过程中，需要预防服务器硬盘故障，以便服务器快速恢复运行，减少数据损耗，尽量减少损失。当服务器硬盘出现故障，我们要怎么应对呢？

    1、评估硬盘故障。   硬盘出现故障，服务器肯定出问题，这时候可以联系机房检查，评估硬盘损坏情况；如果损坏不大，系统还能正常运行，最好先备份数据，再更换硬盘。如果系统已经不能启动，可以更换硬盘重装系统，然后将旧硬盘挂在服务器上，方便备份数据；最坏的情况就是硬盘再也无法运行，里面的数据损失殆尽，一切从头开始。

     2、恢复数据。   硬盘出现故障后，首先关注是数据安全，如果数据损失不严重，硬盘还能正常使用，可以通过专门的软件来恢复；如果数据非常重要，损失很大，硬盘也很难正常使用，这就需要付费请专业的技术公司来 *** 作，千成不要再盲目 *** 作，减小数据恢复机率。
如何预防硬盘故障？

     1、定时备份；     定时备份是服务器管理和维护必须的措施；要预防硬盘故障带来数据损失，可不仅仅服务器里面备份，需要的是异地备份，或者是云备份，这样才能确保硬盘出现故障时，不会对备份数据造成损害。就算硬盘出现故障损失所有数据，有备份数据在，可以将损失降到最低。     

      2、硬盘做raid；     如果服务器硬盘比较大，可以通过raid技术优化整合单个或者多个硬盘，加强服务器硬盘的容错功能，硬盘出现故障时减少数据损失几率，保障服务器正常运行。

      3、经常检测；     在服务器使用过程中，要经常检测硬件性能，早发现早预防，如果检测结果显示硬盘运行数据有问题，那尽快最好备份或者更换硬盘。    在服务器租用和托管时，服务器硬盘出现了故障或者数据丢失先不要慌忙，要冷静。如果自己可以处理的就自己处理；如果自己不能处理，那就关闭服务器，停止硬盘数据的运转，找专业服务器数据恢复公司解决。简单地说就是不要盲目 *** 作，因为这有可能导致数据无法恢复的，请谨记小心。 

                                                                                                                                                     数脉科技

                                                                                                                                                       >