disk_diskgenius - CSDN
  • 磁盘性能分析Disk

    2016-05-17 10:26:04
    Windows性能计数器--磁盘性能分析DiskPhysical Disk:单次IO大小Avg.Disk Bytes/ReadAvg.Disk Bytes/WriteIO响应时间Avg.Disk sec/ReadAvg.Disk sec/WriteIOPSDiskReads/secDiskWrites/secDiskTransfers/secIO吞吐率...
    Windows性能计数器--磁盘性能分析Disk

    Physical Disk:

    单次IO大小

    Avg.Disk Bytes/Read

    Avg.Disk Bytes/Write

    IO响应时间

    Avg.Disk sec/Read

    Avg.Disk sec/Write

    IOPS

    DiskReads/sec

    DiskWrites/sec

    DiskTransfers/sec

    IO吞吐率

    DiskBytes/sec

    DiskRead Bytes/sec

    DiskWrite Bytes/sec

     

    磁盘有两个重要的参数:Seek time、Rotational  latency。

    正常的I/O计数为:①1000/(Seek time+Rotational latency)*0.75,在此范围内属正常。当达到85%的I/O计数以上时则基本认为已经存在I/O瓶颈。理论情况下,磁盘的随机读计数为125、 顺序读计数为225。对于数据文件而言是随机读写,日志文件是顺序读写。因此,数据文件建议存放于RAID5上,而日志文件存放于RAID10或 RAID1中。  

     附:

    15000 RPM:150随机IOPS
    10000 RPM:110随机IOPS
    5400 RPM:50随机IOPS

     

    下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值:  

     

    Avg. DiskQueue Length 12  队列长度

    Avg. DiskSec/Read .035    读数据所用时间ms

    Avg. DiskSec/Write .045    写数据所用时间ms

    DiskReads/sec 320        每秒读数据量

    DiskWrites/sec 100        每秒写数据量

    Avg. DiskQueue Length,12/4=3,每块磁盘的平均队列建议不超过2。  

    Avg. DiskSec/Read一般不要超过11~15ms。  

    Avg. DiskSec/Write一般建议小于12ms。  

     

    从上面的结果,我们看到磁盘本身的I/O能力是满足我们的要求的,原因是因为有大量的请求才导致队列等待,这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后,如果还是不能达到要求,下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求:

    Raid 0 -- I/Os per disk = (reads +writes) / number of disks

    Raid 1 -- I/Os per disk = [reads +(2 * writes)] / 2

    Raid 5 -- I/Os per disk = [reads +(4 * writes)] / number of disks

    Raid 10 -- I/Os per disk = [reads +(2 * writes)] / number of disks  

     

    我们得到的结果是:(320+400)/4=180,这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125,为了达到这个结果:720/125=5.76。就是说要用6块磁盘才能达到这样的要求。  

     

    但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时,大概估算一个平均值,作为计算公式的依据。另一个是你很难从客户那里得到Seek time、 Rotational latency参数的值,这也只能用理论值125进行计算。
    前言

    作为一个数据库管理员,关注系统的性能是日常最重要的工作之一,而在所关注的各方面的性能只能IO性能却是最令人头痛的一块,面对着各种生涩的参数和令人眼花缭乱的新奇的术语,再加上存储厂商的忽悠,总是让我们有种云里雾里的感觉。本系列文章试图从基本概念开始对磁盘存储相关的各种概念进行综合归纳,让大家能够对IO性能相关的基本概念,IO性能的监控和调整有个比较全面的了解。

    在这一部分里我们先舍弃各种结构复杂的存储系统,直接研究一个单独的磁盘的性能问题,藉此了解各个衡量IO系统系能的各个指标以及之间的关系。
    几个基本的概念

    在研究磁盘性能之前我们必须先了解磁盘的结构,以及工作原理。不过在这里就不再重复说明了,关系硬盘结构和工作原理的信息可以参考维基百科上面的相关词条——Hard disk drive(英文)和硬盘驱动器(中文)。
    读写IO(Read/Write IO)操作

    磁盘是用来给我们存取数据用的,因此当说到IO操作的时候,就会存在两种相对应的操作,存数据时候对应的是写IO操作,取数据的时候对应的是读IO操作。
    单个IO操作

    当控制磁盘的控制器接到操作系统的读IO操作指令的时候,控制器就会给磁盘发出一个读数据的指令,并同时将要读取的数据块的地址传递给磁盘,然后磁盘会将读取到的数据传给控制器,并由控制器返回给操作系统,完成一个写IO的操作;同样的,一个写IO的操作也类似,控制器接到写的IO操作的指令和要写入的数据,并将其传递给磁盘,磁盘在数据写入完成之后将操作结果传递回控制器,再由控制器返回给操作系统,完成一个写IO的操作。单个IO操作指的就是完成一个写IO或者是读IO的操作。
    随机访问(Random Access)与连续访问(Sequential Access)

    随机访问指的是本次IO所给出的扇区地址和上次IO给出扇区地址相差比较大,这样的话磁头在两次IO操作之间需要作比较大的移动动作才能重新开始读/写数据。相反的,如果当次IO给出的扇区地址与上次IO结束的扇区地址一致或者是接近的话,那磁头就能很快的开始这次IO操作,这样的多个IO操作称为连续访问。因此尽管相邻的两次IO操作在同一时刻发出,但如果它们的请求的扇区地址相差很大的话也只能称为随机访问,而非连续访问。
    顺序IO模式(Queue Mode)/并发IO模式(BurstMode)

    磁盘控制器可能会一次对磁盘组发出一连串的IO命令,如果磁盘组一次只能执行一个IO命令时称为顺序IO;当磁盘组能同时执行多个IO命令时,称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上,单块磁盘只能一次处理一个IO命令。

     
    单个IO的大小(IO ChunkSize)

    熟悉数据库的人都会有这么一个概念,那就是数据库存储有个基本的块大小(Block Size),不管是SQL Server还是Oracle,默认的块大小都是8KB,就是数据库每次读写都是以8k为单位的。那么对于数据库应用发出的固定8k大小的单次读写到了写磁盘这个层面会是怎么样的呢,就是对于读写磁盘来说单个IO操作操作数据的大小是多少呢,是不是也是一个固定的值?答案是不确定。首先操作系统为了提高 IO的性能而引入了文件系统缓存(File System Cache),系统会根据请求数据的情况将多个来自IO的请求先放在缓存里面,然后再一次性的提交给磁盘,也就是说对于数据库发出的多个8K数据块的读操作有可能放在一个磁盘读IO里就处理了。还有对于有些存储系统也是提供了缓存(Cache)的,接收到操作系统的IO请求之后也是会将多个操作系统的 IO请求合并成一个来处理。不管是操作系统层面的缓存还是磁盘控制器层面的缓存,目的都只有一个,提高数据读写的效率。因此每次单独的IO操作大小都是不一样的,它主要取决于系统对于数据读写效率的判断。

    当一次IO操作大小比较小的时候我们成为小的IO操作,比如说1K,4K,8K这样的;当一次IO操作的数据量比较的的时候称为大IO操作,比如说32K,64K甚至更大。

    在我们说到块大小(Block Size)的时候通常我们会接触到多个类似的概念,像我们上面提到的那个在数据库里面的数据最小的管理单位,Oralce称之为块(Block),大小一般为8K,SQL Server称之为页(Page),一般大小也为8k。在文件系统里面我们也能碰到一个文件系统的块,在现在很多的Linux系统中都是4K(通过 /usr/bin/time -v可以看到),它的作用其实跟数据库里面的块/页是一样的,都是为了方便数据的管理。但是说到单次IO的大小,跟这些块的大小都是没有直接关系的,在英文里单次IO大小通常被称为是IO Chunk Size,不会说成是IO Block Size的。
    IOPS(IO per Second)

    IOPS,IO系统每秒所执行IO操作的次数,是一个重要的用来衡量系统IO能力的一个参数。对于单个磁盘组成的IO系统来说,计算它的IOPS不是一件很难的事情,只要我们知道了系统完成一次IO所需要的时间的话我们就能推算出系统IOPS来。

    现在我们就来推算一下磁盘的IOPS,假设磁盘的转速(Rotational Speed)为15K RPM,平均寻道时间为5ms,最大传输速率为40MB/s(这里将读写速度视为一样,实际会差别比较大)。

    对于磁盘来说一个完整的IO操作是这样进行的:当控制器对磁盘发出一个IO操作命令的时候,磁盘的驱动臂(ActuatorArm)带读写磁头(Head)离开着陆区(LandingZone,位于内圈没有数据的区域),移动到要操作的初始数据块所在的磁道(Track)的正上方,这个过程被称为寻址(Seeking),对应消耗的时间被称为寻址时间(SeekTime);但是找到对应磁道还不能马上读取数据,这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正上方的之后才能开始读取数据,在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(RotationalDelay);接下来就随着盘片的旋转,磁头不断的读/写相应的数据块,直到完成这次IO所需要操作的全部数据,这个过程称为数据传送(DataTransfer),对应的时间称为传送时间(TransferTime)。完成这三个步骤之后一次IO操作也就完成了。

    在我们看硬盘厂商的宣传单的时候我们经常能看到3个参数,分别是平均寻址时间、盘片旋转速度以及最大传送速度,这三个参数就可以提供给我们计算上述三个步骤的时间。

    第一个寻址时间,考虑到被读写的数据可能在磁盘的任意一个磁道,既有可能在磁盘的最内圈(寻址时间最短),也可能在磁盘的最外圈(寻址时间最长),所以在计算中我们只考虑平均寻址时间,也就是磁盘参数中标明的那个平均寻址时间,这里就采用当前最多的10krmp硬盘的5ms。

    第二个旋转延时,和寻址一样,当磁头定位到磁道之后有可能正好在要读写扇区之上,这时候是不需要额外额延时就可以立刻读写到数据,但是最坏的情况确实要磁盘旋转整整一圈之后磁头才能读取到数据,所以这里我们也考虑的是平均旋转延时,对于10krpm的磁盘就是(60s/15k)*(1/2)= 2ms。

    第三个传送时间,磁盘参数提供我们的最大的传输速度,当然要达到这种速度是很有难度的,但是这个速度却是磁盘纯读写磁盘的速度,因此只要给定了单次IO的大小,我们就知道磁盘需要花费多少时间在数据传送上,这个时间就是IOChunk Size / Max Transfer Rate。

    现在我们就可以得出这样的计算单次IO时间的公式:

    IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO ChunkSize/Transfer Rate

    于是我们可以这样计算出IOPS

    IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IOChunk Size/Transfer Rate)

    对于给定不同的IO大小我们可以得出下面的一系列的数据

    4K (1/7.1 ms = 140 IOPS)
        5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 0.1 = 7.1
    8k (1/7.2 ms = 139 IOPS)
        5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 0.2 = 7.2
    16K (1/7.4 ms = 135 IOPS)
        5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 0.4 = 7.4
    32K (1/7.8 ms = 128 IOPS)
        5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 0.8 = 7.8
    64K (1/8.6 ms = 116 IOPS)
        5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 1.6 = 8.6

    从上面的数据可以看出,当单次IO越小的时候,单次IO所耗费的时间也越少,相应的IOPS也就越大。

    上面我们的数据都是在一个比较理想的假设下得出来的,这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时,这个假设其实是比较符合我们实际情况中的随机读写,在随机读写中,每次IO操作的寻址时间和旋转延时都不能忽略不计,有了这两个时间的存在也就限制了IOPS的大小。现在我们考虑一种相对极端的顺序读写操作,比如说在读取一个很大的存储连续分布在磁盘的文件,因为文件的存储的分布是连续的,磁头在完成一个读IO操作之后,不需要从新的寻址,也不需要旋转延时,在这种情况下我们能到一个很大的IOPS值,如下

    4K (1/0.1 ms = 10000 IOPS)
        0ms + 0ms + 4K/40MB = 0.1
    8k (1/0.2 ms = 5000 IOPS)
        0ms + 0ms + 8K/40MB = 0.2
    16K (1/0.4 ms = 2500 IOPS)
        0ms + 0ms + 16K/40MB = 0.4
    32K (1/0.8 ms = 1250 IOPS)
        0ms + 0ms + 32K/40MB = 0.8
    64K (1/1.6 ms = 625 IOPS)
        0ms + 0ms + 64K/40MB = 1.6

    相比第一组数据来说差距是非常的大的,因此当我们要用IOPS来衡量一个IO系统的系能的时候我们一定要说清楚是在什么情况的IOPS,也就是要说明读写的方式以及单次IO的大小,当然在实际当中,特别是在OLTP的系统的,随机的小IO的读写是最有说服力的。
    传输速度(Transfer Rate)/吞吐率(Throughput)

    现在我们要说的传输速度(另一个常见的说法是吞吐率)不是磁盘上所表明的最大传输速度或者说理想传输速度,而是磁盘在实际使用的时候从磁盘系统总线上流过的数据量。有了IOPS数据之后我们是很容易就能计算出对应的传输速度来的

    Transfer Rate = IOPS * IO Chunk Size

    还是那上面的第一组IOPS的数据我们可以得出相应的传输速度如下

    4K: 140 * 4K =  560K / 40M = 1.36%
     8K: 139 * 8K = 1112K / 40M = 2.71%
    16K: 135 * 16K = 2160K / 40M = 5.27%
    32K: 116 * 32K = 3712K / 40M = 9.06%

    可以看出实际上的传输速度是很小的,对总线的利用率也是非常的小。

    这里一定要明确一个概念,那就是尽管上面我们使用IOPS来计算传输速度,但是实际上传输速度和IOPS是没有直接关系,在没有缓存的情况下它们共同的决定因素都是对磁盘系统的访问方式以及单个IO的大小。对磁盘进行随机访问时候我们可以利用IOPS来衡量一个磁盘系统的性能,此时的传输速度不会太大;但是当对磁盘进行连续访问时,此时的IOPS已经没有了参考的价值,这个时候限制实际传输速度却是磁盘的最大传输速度。因此在实际的应用当中,只会用IOPS 来衡量小IO的随机读写的性能,而当要衡量大IO连续读写的性能的时候就要采用传输速度而不能是IOPS了。
    IO响应时间(IOResponse Time)

    最后来关注一下能直接描述IO性能的IO响应时间。IO响应时间也被称为IO延时(IOLatency),IO响应时间就是从操作系统内核发出的一个读或者写的IO命令到操作系统内核接收到IO回应的时间,注意不要和单个IO时间混淆了,单个IO时间仅仅指的是IO操作在磁盘内部处理的时间,而IO响应时间还要包括IO操作在IO等待队列中所花费的等待时间。

    计算IO操作在等待队列里面消耗的时间有一个衍生于利托氏定理(Little’sLaw)的排队模型M/M/1模型可以遵循,由于排队模型算法比较复杂,到现在还没有搞太明白(如果有谁对M/M/1模型比较精通的话欢迎给予指导),这里就罗列一下最后的结果,还是那上面计算的IOPS数据来说:

    8K IO Chunk Size (135 IOPS, 7.2 ms)
        135 => 240.0 ms
        105 => 29.5 ms
        75  => 15.7 ms
        45  => 10.6 ms
     
    64K IO Chunk Size(116 IOPS, 8.6 ms)
        135 => 没响应了……
        105 => 88.6 ms
        75  => 24.6 ms
        45  => 14.6 ms

    从上面的数据可以看出,随着系统实际IOPS越接近理论的最大值,IO的响应时间会成非线性的增长,越是接近最大值,响应时间就变得越大,而且会比预期超出很多。一般来说在实际的应用中有一个70%的指导值,也就是说在IO读写的队列中,当队列大小小于最大IOPS的70%的时候,IO的响应时间增加会很小,相对来说让人比较能接受的,一旦超过70%,响应时间就会戏剧性的暴增,所以当一个系统的IO压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。

    另外补充说一下这个70%的指导值也适用于CPU响应时间,这也是在实践中证明过的,一旦CPU超过70%,系统将会变得受不了的慢。很有意思的东西。

    从上一篇文章的计算中我们可以看到一个15k转速的磁盘在随机读写访问的情况下IOPS竟然只有140左右,但在实际应用中我们却能看到很多标有5000IOPS甚至更高的存储系统,有这么大IOPS的存储系统怎么来的呢?这就要归结于各种存储技术的使用了,在这些存储技术中使用最广的就是高速缓存(Cache)和磁盘冗余阵列(RAID)了,本文就将探讨缓存和磁盘阵列提高存储IO性能的方法。
    高速缓存(Cache)

    在当下的各种存储产品中,按照速度从快到慢应该就是内存>闪存>磁盘>磁带了,然而速度越快也就意味着价格越高,闪存虽然说是发展势头很好,但目前来说却还是因为价格问题无法普及,因此现在还是一个磁盘作霸王的时代。与CPU和内存速度相比,磁盘的速度无疑是计算机系统中最大的瓶颈了,所以在必须使用磁盘而又想提高性能的情况下,人们想出了在磁盘中嵌入一块高速的内存用来保存经常访问的数据从而提高读写效率的方法来折中的解决,这块嵌入的内存就被称为高速缓存。

    说到缓存,这东西应用现在已经是无处不在,从处于上层的应用,到操作系统层,再到磁盘控制器,还有CPU内部,单个磁盘的内部也都存在缓存,所有这些缓存存在的目的都是相同的,就是提高系统执行的效率。当然在这里我们只关心跟IO性能相关的缓存,与IO性能直接相关的几个缓存分别是文件系统缓存(FileSystem Cache)、磁盘控制器缓存(DiskController Cache)和磁盘缓存(DiskCache,也称为DiskBuffer),不过当在计算一个磁盘系统性能的时候文件系统缓存也是不会考虑在内的,因此我们重点考察的就是磁盘控制器缓存和磁盘缓存。

    不管是控制器缓存还是磁盘缓存,他们所起的作用主要是分为三部分:缓存数据、预读(Read-ahead)和回写(Write-back)。

     

    缓存数据

    首先是系统读取过的数据会被缓存在高速缓存中,这样下次再次需要读取相同的数据的时候就不用在访问磁盘,直接从缓存中取数据就可以了。当然使用过的数据也不可能在缓存中永久保留的,缓存的数据一般那是采取LRU算法来进行管理,目的是将长时间不用的数据清除出缓存,那些经常被访问的却能一直保留在缓存中,直到缓存被清空。

    预读

    预读是指采用预读算法在没有系统的IO请求的时候事先将数据从磁盘中读入到缓存中,然后在系统发出读IO请求的时候,就会实现去检查看看缓存里面是否存在要读取的数据,如果存在(即命中)的话就直接将结果返回,这时候的磁盘不再需要寻址、旋转等待、读取数据这一序列的操作了,这样是能节省很多时间的;如果没有命中则再发出真正的读取磁盘的命令去取所需要的数据。

     

    缓存的命中率跟缓存的大小有很大的关系,理论上是缓存越大的话,所能缓存的数据也就越多,这样命中率也自然越高,当然缓存不可能太大,毕竟成本在那儿呢。如果一个容量很大的存储系统配备了一个很小的读缓存的话,这时候问题会比较大的,因为小缓存的数据量非常小,相比整个存储系统来说比例非常低,这样随机读取(数据库系统的大多数情况)的时候命中率也自然就很低,这样的缓存不但不能提高效率(因为绝大部分读IO都还要读取磁盘),反而会因为每次去匹配缓存而浪费时间。

    执行读IO操作是读取数据存在于缓存中的数量与全部要读取数据的比值称为缓存命中率(ReadCache Hit Radio),假设一个存储系统在不使用缓存的情况下随机小IO读取能达到150IOPS,而它的缓存能提供10%的缓存命中率的话,那么实际上它的IOPS可以达到150/(1-10%)=166。

    回写

    首先说一下,用于回写功能的那部分缓存被称为写缓存(WriteCache)。在一套写缓存打开的存储中,操作系统所发出的一系列写IO命令并不会被挨个的执行,这些写IO的命令会先写入缓存中,然后再一次性的将缓存中的修改推到磁盘中,这就相当于将那些相同的多个IO合并成一个,多个连续操作的小IO合并成一个大的IO,还有就是将多个随机的写IO变成一组连续的写IO,这样就能减少磁盘寻址等操作所消耗的时间,大大的提高磁盘写入的效率。

     

    读缓存虽然对效率提高是很明显的,但是它所带来的问题也比较严重,因为缓存和普通内存一样,掉点以后数据会全部丢失,当操作系统发出的写IO命令写入到缓存中后即被认为是写入成功,而实际上数据是没有被真正写入磁盘的,此时如果掉电,缓存中的数据就会永远的丢失了,这个对应用来说是灾难性的,目前解决这个问题最好的方法就是给缓存配备电池了,保证存储掉电之后缓存数据能如数保存下来。

    和读一样,写缓存也存在一个写缓存命中率(WriteCache Hit Radio),不过和读缓存命中情况不一样的是,尽管缓存命中,也不能将实际的IO操作免掉,只是被合并了而已。

    控制器缓存和磁盘缓存除了上面的作用之外还承当着其他的作用,比如磁盘缓存有保存IO命令队列的功能,单个的磁盘一次只能处理一个IO命令,但却能接收多个IO命令,这些进入到磁盘而未被处理的命令就保存在缓存中的IO队列中。
    RAID(Redundant Array Of InexpensiveDisks)

    如果你是一位数据库管理员或者经常接触服务器,那对RAID应该很熟悉了,作为最廉价的存储解决方案,RAID早已在服务器存储中得到了普及。在RAID的各个级别中,应当以RAID10和RAID5(不过RAID5已经基本走到头了,RAID6正在崛起中,看看这里了解下原因)应用最广了。下面将就RAID0,RAID1,RAID5,RAID6,RAID10这几种级别的RAID展开说一下磁盘阵列对于磁盘性能的影响,当然在阅读下面的内容之前你必须对各个级别的RAID的结构和工作原理要熟悉才行,这样才不至于满头雾水,推荐查看wikipedia上面的如下条目:RAID,StandardRAID levels,Nested RAID levels。

    RAID0

    RAID0将数据条带化(striping)将连续的数据分散在多个磁盘上进行存取,系统发出的IO命令(不管读IO和写IO都一样)就可以在磁盘上被并行的执行,每个磁盘单独执行自己的那一部分请求,这样的并行的IO操作能大大的增强整个存储系统的性能。假设一个RAID0阵列有n(n>=2)个磁盘组成,每个磁盘的随机读写的IO能力都达到140的话,那么整个磁盘阵列的IO能力将是140*n。同时如果在阵列总线的传输能力允许的话RAID0的吞吐率也将是单个磁盘的n倍。

    RAID1

    RAID1在容量上相当于是将两个磁盘合并成一个磁盘来使用了,互为镜像的两个磁盘里面保存的数据是完全一样的,因此在并行读取的时候速度将是n个磁盘速度的总和,但是写入就不一样了,每次写入都必须同时写入到两个磁盘中,因此写入速度只有n/2。

    RAID5

    我们那一个有n(n>=3)个磁盘的RAID5阵列来看,首先看看RAID5阵列的读IO,RAID5是支持并行IO的,而磁盘上的数据呈条带状的分布在所有的磁盘上,因此读IO的速度相当于所有磁盘速度的总和。不过这是在没有磁盘损坏的情况下,当有一个磁盘故障的时候读取速度也是会下降的,因为中间需要花时间来计算丢失磁盘上面的数据。

    读取数据的情况相对就要复杂的多了,先来看下RAID5奇偶校验数据写入的过程,我们把写入的数据称为D1,当磁盘拿到一个写IO的命令的时候,它首先会读取一次要写入的地址的数据块中修改之前的数据D0,然后再读取到当前条带中的校验信息P0,接下来就根据D0,P0,D1这三组数据计算出数据写入之后的条带的奇偶校验信息P1,最后发出两个写IO的命令,一个写入D1,另一个写入奇偶校验信息P1。可以看出阵列在实际操作的时候需要读、读、写、写一共4个 IO才能完成一次写IO操作,也就是实际上的写入速度只有所有磁盘速度总和的1/4。从这点可以看出RAID5是非常不适合用在要大批量写入数据的系统上的。

    RAID6

    RAID6和RAID5很类似,差别就在于RAID6多了一个用于校验的磁盘。就读IO速度上来说这两个是完全一样的,都是所有磁盘IO速度的总和。

    在写IO上也很是类似,不同的是RAID将一个命令分成了三次读、三次写一共6次IO命令才能完成,也就是RAID6实际写入磁盘的速度是全部磁盘速度之和的1/6。可以看出从写IO看RAID6比RAID5差别是很大的。

    RAID10

    RAID0 读写速度都很好,却没有冗余保护;RAID5和RAID6都有同样的毛病就是写入的时候慢,读取的时候快。那么RAID1呢?嗯,这里要说的就是RAID1,其实不管是RAID10还是RAID01,其实都是组合大于2块磁盘时候的RAID1,当先镜像后条带时候就称为RAID10,先条带后镜像的时候称为RAID01。从性能上看RAID01和RAID10都是一样的,都是RAID1嘛,但是RAID10在重建故障磁盘的时候性能比RAID01 要快。因为RAID10其实就是RAID1,所以它的性能与RAID1也就是一样的了,这里不需要再做过多的讨论。
    四个性能指标的变化
    IO响应时间(IOResponse Time)

    在任何时候IO响应时间值得都是单个IO的响应时间,因此,不管磁盘是否组成了磁盘阵列,它的IO响应时间应该都是一样的。从前面的计算中我们可以看到,如果IO响应时间在10ms左右的话是很正常的,但是当IO响应时间比这个值超出太多的时候,你就要开始注意了,很可能就意味着此时你的磁盘系统已经成为了一个瓶颈。
    IOPS

    综合上面两个部分的讨论我们来估算一下阵列下的磁盘总体IOPS,在这里我们先假设组成阵列的单个磁盘的随机读写的IOPS为140,读写缓存命中率都为10%,组成阵列的磁盘个数为4。

    因为不管是那种阵列,磁盘的读取性能都是所有磁盘之和,所以可以得出下面的读取IOPS:

    read IOPS = disk_IOPS/(1-read_cache_hit_ratio)*disk_num =140/(1-10%)*4 = 622

    而写入性能就完全不一样了,根据上面的讨论我们可以得出下面结论:

    RAID0: 1 IO request => need 1 actual IO on disk
    RAID1: 1 IO request => need 2 actual IO on disk
    RAID5: 1 IO request => need 4 actual IO on disk
    RAID6: 1 IO request => need 6 actual IO on disk

    由此我们也可以计算出写入IOPS估算公式:

    RAID0 write IOPS =disk_IOPS/(1-write_cache_hit_ratio)*disk_num/acture_IO_num =140/(1-10%)*4/1 = 622
    RAID1 write IOPS =disk_IOPS/(1-write_cache_hit_ratio)*disk_num/acture_IO_num =140/(1-10%)*4/2 = 311
    RAID5 write IOPS =disk_IOPS/(1-write_cache_hit_ratio)*disk_num/acture_IO_num =140/(1-10%)*4/4 = 155
    RAID6 write IOPS =disk_IOPS/(1-write_cache_hit_ratio)*disk_num/acture_IO_num =140/(1-10%)*4/6 = 103

    实际上从通过上面的计算方法我们还可以估算当给定一个要求的IOPS的情况下,估计下使用各个阵列级别所需要的磁盘的数量。当然我们上面的计算方法只是一个估算,我们忽略很多其他的因素,得出的只是一个大概的数值,不过在实际的应用还是有一定的参考作用的。

    本篇最后附送一个计算磁盘系统IOPS的网站――wmarow’s disk & disk array calculator,这个网站提供的计算公式还考虑了诸如阵列条带大小以及主机方面的因素,很有参考价值,至于怎么选择合适的条带大小,请参考【延伸阅读】部分。


    传输速度(Transfer Rate)/吞吐率(Throughput)

    实际上估算除了随机读写的IOPS也就知道了随机读写的吞吐率。对于顺序读写的呢,还是跟前一篇所讲的一样,主要受限于磁盘的限制,不能再拿IOPS来衡量了。

    random_throughtput = random_IOPS * IO_chunk_size
    展开全文
  • biosdisk的用法

    2005-08-05 14:59:00
    函数名: biosdisk 功 能: 软硬盘I/O 用 法: int biosdisk(int cmd, int drive, int head, int track, int sector int nsects, void *buffer); 本函数用来对驱动器作一定的操作,cmd为功能号, drive为驱动器号...

    函数名: biosdisk
    功  能: 软硬盘I/O
    用  法: int biosdisk(int cmd, int drive, int head, int track, int sector
       int nsects, void *buffer);

           本函数用来对驱动器作一定的操作,cmd为功能号,
           drive为驱动器号(0=A,1=B,0x80=C,0x81=D,0x82=E等)。
          
           cmd可为以下值:
            0 重置软磁盘系统.这强迫驱动器控制器来执行硬复位.忽略所有其它参数.
            1 返回最后的硬盘操作状态.忽略所有其它参数
            2 读一个或多个磁盘扇区到内存.读开始的扇区由head、track、sector给出。
              扇区号由nsects给出。把每个扇区512个字节的数据读入buffer
            3 从内存读数据写到一个或多个扇区。写开始的扇区由head、track、sector
              给出。扇区号由nsects给出。所写数据在buffer中,每扇区512个字节。
            4 检验一个或多个扇区。开始扇区由head、track、sector给出。扇区号由
              nsects给出。
            5 格式化一个磁道,该磁道由head和track给出。buffer指向写在指定track上
              的扇区磁头器的一个表。
              以下cmd值只允许用于XT或AT微机:
            6 格式化一个磁道,并置坏扇区标志。
            7 格式化指定磁道上的驱动器开头。
            8 返回当前驱动器参数,驱动器信息返回写在buffer中(以四个字节表示)。
            9 初始化一对驱动器特性。
           10 执行一个长的读,每个扇区读512加4个额外字节
           11 执行一个长的写,每个扇区写512加4个额外字节
           12 执行一个磁盘查找
           13 交替磁盘复位
           14 读扇区缓冲区
           15 写扇区缓冲区
           16 检查指定的驱动器是否就绪
           17 复核驱动器
           18 控制器RAM诊断
           19 驱动器诊断
           20 控制器内部诊

           函数返回由下列位组合成的状态字节:
           0x00 操作成功
           0x01 坏的命令
           0x02 地址标记找不到
           0x04 记录找不到
           0x05 重置失败
           0x07 驱动参数活动失败
           0x09 企图DMA经过64K界限
           0x0B 检查坏的磁盘标记
           0x10 坏的ECC在磁盘上读
           0x11 ECC校正的数据错误(注意它不是错误)
           0x20 控制器失效
           0x40 查找失败
           0x80 响应的连接失败
           0xBB 出现无定义错误
           0xFF 读出操作失败

    程序例:
    // main.c
    #include <stdio.h>
    #include <bios.h>
    #include "floppyio.h"
    int main(void)
    {
     char buf[512] = "Hello, world!";

     int r;

     FILE *fp = fopen("booter.exe", "rb");
     fread(buf, 1, 512, fp);
     fclose(fp);

     printf("floppy ready : %d/n", IsFloppyReady());

     
     buf[510] = 0x55;
     buf[511] = 0xaa;

     printf("write: %d,%d/n", buf[510], buf[511]);
     r = WriteFloppyBootSection(buf);
     printf("r=%d/n", r);


     return 0;
    }


    // FloppyIO.h
    /* defines */
    #define FLOPPY_READ  2
    #define FLOPPY_WRITE 3
    #define FLOPPY_READY 4

    /* test if floppy is ready now, if so return 1, else 0 */
    int IsFloppyReady(void);

    /* write first head 0 /track 0 /sector 1 of floppy disk (boot section, 512 bytes) */
    int WriteFloppyBootSection(char* buffer);

    /* read first head 0 /track 0 /sector 1 of floppy disk (boot section, 512 bytes) */
    int ReadFloppyBootSection(char* buffer);


    // FloppyIO.c
    #include "FloppyIO.h"
    int IsFloppyReady(void)
    {
     int result;
     char buffer[512];

     result = biosdisk(FLOPPY_READY, 0, 0, 0, 1, 1, buffer);
     
     return ( result == 0 ? 1 : 0 );
    }

    int WriteFloppyBootSection(char* buffer)
    {
     int result;

     result = biosdisk(FLOPPY_WRITE, 0, 0, 0, 1, 1, buffer);
     
     return ( result == 0 ? 1 : 0 );
    }

    int ReadFloppyBootSection(char* buffer)
    {
     int result;
     
     result = biosdisk(FLOPPY_READ, 0, 0, 0, 1, 1, buffer);
     
     return ( result == 0 ? 1 : 0 );
    }

    展开全文
  • LruCache是内存缓存,DiskLruCache对应的磁盘缓存。在学习Bitmap缓存优化的时候学习了这两种缓存方式,我觉得这种策略可以应用于Android的开发中(现在应该都是这样应用的吧),它不仅仅是Bitmap,它可以是商品,也...

        LruCache是内存缓存,DiskLruCache对应的磁盘缓存。在学习Bitmap缓存优化的时候学习了这两种缓存方式,我觉得这种策略可以应用于Android的开发中(现在应该都是这样应用的吧),它不仅仅是Bitmap,它可以是商品,也可以是一组数据。现在就以Bitmap为案例,把我知道的关于Bitmap缓存的知识都记录下来。

      LruCache的使用

      LruCache在androidx.collection包下有这样一个类。先说说它的基本使用,首先创建LruCache的实例并分配给它内存的大小,然后重写sizeof方法返回每个Bitmap所占的内存。

    // 应用可分配的最大内存数(这里转换为k字节)
            int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
            // 分配内存1/8给Bitmap缓存
            int cacheSize = maxMemory / 8;
            mBitmapLruCache = new LruCache<String, Bitmap>(cacheSize) {
                @Override
                protected int sizeOf(@NonNull String key, @NonNull Bitmap bitmap) {
                    // 每个Bitmap所占的内存数
                    return bitmap.getByteCount() / 1024;
                }
            };

       然后当我们去加载Bitmap的时候,首先去LruCache中查找,如果有就直接从内存中取出,如果没有就从网络下载下来进行加载,并把Bitmap存进LruCache中。LruCache大概的策略就是这样。LruCache里面维护了一个LinkedHashMap,它是一个链表,我们可以把它理解成队列。这个LinkedHashMap初始化的时候使用访问顺序作为队列排列的规则,也就是说这个队列是根据访问的顺序从队头到队尾一次排列的。当我们的图片足够多,队列不足以存储我们的图片的时候,队列就会淘汰掉最近最少访问的Bitmap,也就是队尾的Bitmap。

             

               

        LruCache的源码解析

        ok,上面简单的说明LruCache策略和简单使用,下面我们看看它代码是怎么实现的。

        在看源码之前,这里有必要补充下,首先我们看到LruCache类注释,它说android.util.LruCache包下有个LruCache类,它曾经运行在api12之前的。这个包下LruCache我看了下与androidx.collection包下LruCache代码几乎都相同,不同的是,当队列缓存不足的时候它淘汰的是队列头部的元素,经我查阅其他博客,发现在Java某个版本之前LinkedHashMap插入元素采用的尾插法,而现在的是头插法,就是说它的排列顺序和现在的是相反的,自然淘汰的位置也是相反的。

        好的,我们继续回到LruCache源码解析。

        我们现在LruCache的构造方法,它使用maxSize保存内存缓存的大小, 然后初始化LinkedHashMap,注意到LinkedHashMap的第三个参数,如果设置为false,则队列的排列顺序是按照插入顺序排序的,true则访问顺序排序。

              

        接着,看看它的get方法

     @Nullable
        public final V get(@NonNull K key) {
            if (key == null) {
                throw new NullPointerException("key == null");
            }
    
            V mapValue;
            synchronized (this) {
                mapValue = map.get(key);
                if (mapValue != null) {
                    hitCount++;
                    return mapValue;
                }
                missCount++;
            }
    
            /*
             * Attempt to create a value. This may take a long time, and the map
             * may be different when create() returns. If a conflicting value was
             * added to the map while create() was working, we leave that value in
             * the map and release the created value.
             */
    
            V createdValue = create(key);
            if (createdValue == null) {
                return null;
            }
    
            synchronized (this) {
                createCount++;
                mapValue = map.put(key, createdValue);
    
                if (mapValue != null) {
                    // There was a conflict so undo that last put
                    map.put(key, mapValue);
                } else {
                    size += safeSizeOf(key, createdValue);
                }
            }
    
            if (mapValue != null) {
                entryRemoved(false, key, createdValue, mapValue);
                return mapValue;
            } else {
                trimToSize(maxSize);
                return createdValue;
            }
        }

        我们传入一个key去取对应的Bitmap,如果存在,则将对应的Bitmap返回并将它移动到队首;如果不存在,则去create一个Bitmap,这个方法默认返回null,如果我们需要去创建一个Bitmap,可以去重写这个方法。在同步块中,将这个新建的Bitmap放入缓存队列中,这里有两种情况的处理:第一中情况,这个key对应的值之前的存在的,它最重新设置进队列中,这个应该是个处理冲突的一个措施。然后调用entryRemoved方法,这个方法也是默认是个空方法。第二种情况,这个key对应的值之前是null,那么它就会调用safeSizeOf方法返回的值加到队列总的缓存中。safeSizeOf方法又调用了sizeOf方法,sizeOf方法默认返回1。

        我们可以这样理解这个sizeOf方法,当我们没有重写sizeOf方法去返回Bitmap占用内存大小,那么我们设置的内存大小maxSize默认是队列可以缓存最大Bitmap的个数;如果像上面那样设置,那么maxSize是队列的可以缓存的最大内存。

             

        接着看trimToSize方法

              

        这方法主要是去判断队列中缓存的Bitmap是超过了我们设定的缓存的大小,如果超过了我们设定的缓存的大小,则需要移除队列中最近最少访问的条目。size保存的是队列中所有元素的总的内存,maxSize是我们分配的内存。

        我们再看看put方法

            

        这个方法里面的调用的方法上面都介绍过了,主要的逻辑在同步块里,入队设置的元素,并添加元素所占的内存,如果上一个key对应的值不为空,size减去这个值的size。

       

        DiskLruCache的使用

        DiskLruCache磁盘缓存,相对于内存缓存来说它是更慢的,在实际应用中,DiskLruCache通常作为二级缓存。具体的流程应该是这个样子。我们在加载图片的时候,首先去内存缓存(LruCache)中找,没有找到就去磁盘缓存(DiskLruCache)中找,没有找到最后去网络去下载然后解码显示图片,并且将图片保存到磁盘缓存和内存缓存中。

     private void loadImage(ImageView imageView, Beauty item) {
            // 从LruCache中寻找
            Bitmap bitmapFromCache = ImageLoaderUtils.share().getBitmapFromCache(item.getBeautyImg());
            if (bitmapFromCache != null) {
                // 显示图片
                imageView.setImageBitmap(bitmapFromCache);
            } else {
                imageView.setImageResource(R.mipmap.ic_launcher);
                // 内存缓存中没有,开启一个子线程寻找
                TaskScheduler.execute(new Task<Bitmap>() {
                    @Override
                    public Bitmap doInBackground() {
                        synchronized (mDiskLock) {
                            // 从DiskLruCache寻找
                            Bitmap bitmapFromDiskCache = DiskLruCacheUtils.share().getBitmapFromDiskCache(item.getBeautyImg());
                            if (bitmapFromDiskCache == null) {
                                Log.d(TAG, "bitmapFromDiskCache == null ");
                                // 从网络中下载
                                bitmapFromDiskCache = decodeURL(item.getBeautyImg());
                            }
                            return bitmapFromDiskCache;
                        }
                    }
    
                    @Override
                    public void onSuccess(Bitmap bitmap) {
                        if (bitmap != null) {
                            // 获取图片成功并显示图片
                            ImageLoaderUtils.share().addBitmapToCache(bitmap, item.getBeautyImg());
                            imageView.setImageBitmap(bitmap);
                        }
                    }
    
                });
            }
        }

     

        

        

    展开全文
  • 这段时间一直很忙,很久没有写博客了,前几天帮一个朋友重装系统,结果朋友电脑拿回去之后发现开机停留在了disk error ,please enter any to restart这个界面,随意按键之后重启仍然是这个现象,这也着实让我恼火了...

    这段时间一直很忙,很久没有写博客了,前几天帮一个朋友重装系统,结果朋友电脑拿回去之后发现开机停留在了disk error ,please enter any to restart这个界面,随意按键之后重启仍然是这个现象,这也着实让我恼火了好大一会儿,下面跟大家讲讲出现这种状况的几种解决办法:

     

    1.拔下电脑上插着的U盘或者鼠标键盘,重启。

        因为安装系统的时候可能需要把系统调成U盘启动,之后安装完了如果忘了改回来,你的系统每次开机都会监测有没有U盘连着,如果有,它就会试着从U盘启动,这样就会出现disk error ,please enter any to restart的现象。
     

    2.磁盘数据线没有插稳,方法是取下重新插稳插好。

    因为电脑时间用久了之后,硬盘等硬件的连接线可能会出现松动,导致系统启动是进入硬盘出现接触不良的状况。


    3.使用windows优化大师进行修复

    磁盘错误,出现了坏扇区或者坏道,如果检查出有的话 就是这个问题了 。换回去看看 如果还不行只有格硬盘了。

    如果这样还不能修复的话 只有送去检修了
    修硬盘的话得看是哪个部件坏掉了,如果是盘体坏了,就不用修了,一般也没法修......


    展开全文
  • InsPro Disk 绝对虚拟硬盘软件 虚拟硬盘软件,虚拟出的硬盘与真实硬盘一样可以进行分区、格式化等操作。 我经常在做数据恢复过程中用到它,比如以前要使用easy recovery,recovery my files等扫描工具 恢复 镜像文件...
  • Ghost的Disk菜单下的子菜单项可以实现硬盘到硬盘的直接对拷(Disk-To Disk)、硬盘到镜像文件(Disk-To Image)、从镜像文件还原硬盘内容(Disk-From Image)。 在多台电脑的配置完全相同的情况下,我们可以...
     
    Ghost的Disk菜单下的子菜单项可以实现硬盘到硬盘的直接对拷(Disk-To Disk)、硬盘到镜像文件(Disk-To Image)、从镜像文件还原硬盘内容(Disk-From Image)。

    在多台电脑的配置完全相同的情况下,我们可以先在一台电脑上安装好操作系统及软件,然后用ghost的硬盘对拷功能将系统完整地“复制”一份到其它电脑,这样装操作系统可比传统方法快多了哦:)。

    Ghost的Disk菜单各项使用与Partition大同小异,而且使用也不是很多,在此就不赘述了。

    完全版:
    克隆软件Ghost初级使用教程

    一、什么是Ghost ?

    Ghost(幽灵)软件是美国赛门铁克公司推出的一款出色的硬盘备份还原工具,可以实现FAT16、FAT32、NTFS、OS2等多种硬盘分区格式的分区及硬盘的备份还原。俗称克隆软件。

    1、特点:既然称之为克隆软件,说明其Ghost的备份还原是以硬盘的扇区为单位进行的,也就是说可以将一个硬盘上的物理信息完整复制,而不仅仅是数据的简单复制;克隆人只能克隆躯体,但这个Ghost却能克隆系统中所有的东东,包括声音动画图像,连磁盘碎片都可以帮你复制,比克隆人还厉害哟:)。Ghost支持将分区或硬盘直接备份到一个扩展名为.gho的文件里(赛门铁克把这种文件称为镜像文件),也支持直接备份到另一个分区或硬盘里。

    2、运行ghost:至今为止,ghost只支持Dos的运行环境,这不能说不是一种遗憾:(。我们通常把ghost文件复制到启动软盘(U盘)里,也可将其刻录进启动光盘,用启动盘进入Dos环境后,在提示符下输入ghost,回车即可运行ghost,首先出现的是关于界面

    按任意键进入ghost操作界面,出现ghost菜单,主菜单共有4项,从下至上分别为Quit(退出)、Options(选项)、Peer to Peer(点对对,主要用于网络中)、Local(本地)。一般情况下我们只用到Local菜单项,其下有三个子项:Disk(硬盘备份与还原)、Partition(磁盘分区备份与还原)、 Check(硬盘检测),前两项功能是我们用得最多的,下面的操作讲解就是围绕这两项展开的。

    3、由于Ghost在备份还原是按扇区来进行复制,所以在操作时一定要小心,不要把目标盘(分区)弄错了,要不将目标盘(分区)的数据全部抹掉就很惨的……根本没有多少恢复的机会,所以一定要认真、细心!但你也不要太紧张,其实Ghost的使用很简单,弄懂那几个单词的意思你就会理解它的用法,加上认真的态度,你一定可以掌握它的!一起来吧:)

    二、 分区备份

    预备知识:认识单词
    Disk:不用我说你也知道,磁盘的意思;
    Partition:即分区,在操作系统里,每个硬盘盘符(C盘以后)对应着一个分区;
    Image:镜像,镜像是Ghost的一种存放硬盘或分区内容的文件格式,扩展名为.gho;
    To:到,在ghost里,简单理解to即为“备份到”的意思;
    From:从,在ghost里,简单理解from即为“从……还原”的意思。

    (一) Partition菜单简介

    其下有三个子菜单:
    To Partion:将一个分区(称源分区)直接复制到另一个分区(目标分区),注意操作时,目标分区空间不能小于源分区;
    To Image:将一个分区备份为一个镜像文件,注意存放镜像文件的分区不能比源分区小,最好是比源分区大;
    From Image:从镜像文件中恢复分区(将备份的分区还原)。

    (二) 分区镜像文件的制作

    1、 运行ghost后,用光标方向键将光标从“Local”经“Disk”、“Partition”移动到“To Image”菜单项上,然后按回车。

    2、 出现选择本地硬盘窗口,,再按回车键。

    3、 出现选择源分区窗口(源分区就是你要把它制作成镜像文件的那个分区)

    用上下光标键将蓝色光条定位到我们要制作镜像文件的分区上,按回车键确认我们要选择的源分区,再按一下Tab键将光标定位到OK键上(此时OK键变为白色),再按回车键。

    4、 进入镜像文件存储目录,默认存储目录是ghost文件所在的目录,在File name处输入镜像文件的文件名,也可带路径输入文件名(此时要保证输入的路径是存在的,否则会提示非法路径),如输入D:\sysbak\cwin98,表示将镜像文件cwin98.gho保存到D:\sysbak目录下,输好文件名后,再回车。

    5、 接着出现“是否要压缩镜像文件”窗口,有“No(不压缩)、Fast(快速压缩)、High(高压缩比压缩)”,压缩比越低,保存速度越快。一般选Fast即可,用向右光标方向键移动到Fast上,回车确定;

    6、 接着又出现一个提示窗口,用光标方向键移动到“Yes”上,回车确定。

    7、 Ghost开始制作镜像文件

    8、 建立镜像文件成功后,会出现提示创建成功窗口

    回车即可回到Ghost界面;

    9、 再按Q键,回车后即可退出ghost。

    至此,分区镜像文件制作完毕! 也蛮简单的嘛:)。

    三、 从镜像文件还原分区

    制作好镜像文件,我们就可以在系统崩溃后还原,这样又能恢复到制作镜像文件时的系统状态。下面介绍镜像文件的还原。

    (一)在DOS状态下,进入Ghost所在目录,输入Ghost回车,即可运行Ghost。

    (二)出现Ghost主菜单后,用光标方向键移动到菜单“Local-Partition-From Image”,然后回车。

    (三) 出现“镜像文件还原位置窗口”,在File name处输入镜像文件的完整路径及文件名(你也可以用光标方向键配合Tab键分别选择镜像文件所在路径、输入文件名,但比较麻烦),如d:\sysbak\cwin98.gho,再回车。

    (四) 出现从镜像文件中选择源分区窗口,直接回车。
    (五) 又出现选择本地硬盘窗口,再回车。

    (六) 出现选择从硬盘选择目标分区窗口,我们用光标键选择目标分区(即要还原到哪个分区),回车。

    (七) 出现提问窗口,选Yes回车确定,ghost开始还原分区信息。

    (八) 很快就还原完毕,出现还原完毕窗口,选Reset Computer回车重启电脑。


    现在就完成了分区的恢复,是不是很快呀:)。
    注意:选择目标分区时一定要注意选对,否则:(,后果是目标分区原来的数据将全部消失……

    四、 硬盘的备份及还原

    Ghost的Disk菜单下的子菜单项可以实现硬盘到硬盘的直接对拷(Disk-To Disk)、硬盘到镜像文件(Disk-To Image)、从镜像文件还原硬盘内容(Disk-From Image)。

    在多台电脑的配置完全相同的情况下,我们可以先在一台电脑上安装好操作系统及软件,然后用ghost的硬盘对拷功能将系统完整地“复制”一份到其它电脑,这样装操作系统可比传统方法快多了哦:)。

    Ghost的Disk菜单各项使用与Partition大同小异,而且使用也不是很多,在此就不赘述了。

    五、 Ghost使用方案

    1、最佳方案:完成操作系统及各种驱动的安装后,将常用的软件(如杀毒、媒体播放软件、office办公软件等)安装到系统所在盘,接着安装操作系统和常用软件的各种升级补丁,然后优化系统,最后你就可以用启动盘启动到Dos下做系统盘的克隆备份了,注意备份盘的大小不能小于系统盘!

    2、如果你因疏忽,在装好系统一段间后才想起要克隆备份,那也没关系,备份前你最好先将系统盘里的垃圾文件清除,注册表里的垃圾信息清除(推荐用Windows优化大师),然后整理系统盘磁盘碎片,整理完成后到Dos下进行克隆备份。

    3、什么情况下该恢复克隆备份?
    当你感觉系统运行缓慢时(此时多半是由于经常安装卸载软件,残留或误删了一些文件,导致系统紊乱)、系统崩溃时、中了比较难杀除的病毒时,你就要进行克隆还原了!有时如果长时间没整理磁盘碎片,你又不想花上半个小时甚至更长时间整理时,你也可以直接恢复克隆备份,这样比单纯整理磁盘碎片效果要好得多!

    4、最后强调:在备份还原时一定要注意选对目标硬盘或分区!
    展开全文
  • Win7突然无法启动,应该说是启动中卡死,没有别的问题,用安全模式,显示加载disk.sys时卡死。搜索发现很多人遇到这个问题。 实际解决方法是查看数据线,重新插拔,换口,换线。 数据线出现故障往往表现非常奇怪...
  • 今天偶遇一台老电脑,很久都没有用了,而且只有几百兆的内存,160G的硬盘,无奈只好装XP系统,GHOST完之后,开机发现出现a disk read error occurred的错误,但是用U盘引导可以,疑惑不解,马上百度,各种搜,各种...
  • share nothing和share disk

    2018-01-27 00:30:22
    share disk架构下,每个结点有自己的CPU和内存,但是共享同一个存储。也就是说,存储只有一份,放在单独的分布式文件系统上,由文件系统本身来保证其可用性,一般由高端的专门存储设备来完成。 大多数分布式...
  • 树莓派4B的操作系统...向TF卡中烧录系统需要使用win32DiskImager软件,这个软件可以从网上搜索下载,也可以使用本文中提供的软件。 准备好了win32DiskImager软件之后,还需要下载系统的镜像文件。我们对Raspbia...
  • 可能由于不习惯Xcode 8 的...Could not find Developer Disk Image"的问题.解决方法- 打开Finder -&gt; 应用程序 -&gt; Xcode- Xcode右键,显示包内容(依次打开)Contents--&gt;Developer--&gt...
  • 最近在更新时svn发生了这样的一个错误,database disk image is malformed,正是在关键的时候出现这样的问题,真是关键时候掉链子,好了不吐槽了,说一下解决方案。 解决方案有两种 1.重新checkout一下项目工程,...
  • 1.简介disk-usage plugin 是用来记录磁盘使用情况的,既可以统计单个项目的磁盘使用情况,也可以全局统计所有项目的磁盘使用情况2.插件安装1>选择系统管理>管理插件>可选插件, 2>在检索输入框中输入disk,检索到...
  • 原博文链接:http://www.aobosir.com/blog/2017/01/19/Ubuntu-not-enough-free-disk-space-when-upgrading-low-disk-space/当你的Ubuntu系统的真机或者虚拟机使用时间长了,安装下载的软件包多了。同时你的电脑的...
  • 据不可靠统计,有「无数」工具可以实现物理机到虚拟机的(P2V)转换,虽然有很多此类工具都被开发商帖上了高价标签,但至少来自微软 Sysinternals 工具集中的 Disk2VHD 还是可以免费使用的,本文我们就来讨论下使用 ...
  • 开机就出现DISK BOOT FAILURE,INSERT SYSTEM DISK AND PRESS ENTER 我的第一引导是从光驱,第二是从硬盘。 以前是可以正常从硬盘启动的,突然发现这种现象。光驱里面没有光盘,为什么不能从硬盘启动了呢? 开机...
  • 起因因为有两个系统,所以想删除另一个无用系统,然后就开始作死了== 作死的认为格式化失败是因为D盘是活动分区,所以格式化失败 取消将磁盘分区标为活动的: ...使用”LIST DISK”命令确定你的移动硬盘的##号;
  • shared-nothing: 数据以某种方式分区并分布在一组机器上,...与shared-nothing相比,shared-disk的所有数据都可以冲所有集群节点访问。任何机器都可以读取或写入希望的任何数据部分。 如图: 理解writing的权衡 在...
  • 重装系统后,发现开机停留在了disk error ,please enter any to restart这个界面,下面跟大家讲讲出现这种状况的几种解决办法:   1.拔下电脑上插着的U盘或者鼠标键盘,重启。  因为安装系统的时候可能...
  • Metadisk是一个开源软件项目,试图概念性地证明云存储应用可以更加去中心化、更安全并更高效。此外,Metadisk给完全去中心化网络提供了一个原型平台。为追寻这一目标,我们提出开发一个web应用,给非技术人员提供一...
1 2 3 4 5 ... 20
收藏数 396,438
精华内容 158,575
关键字:

disk