手机随时阅读
新人专享大礼包￥24
10年前重复数据删除技术还是存储领域中十分先进的技术手段。10年前李凯带领团队推出了首个基于重复数据删除的备份设备，并且至今一直保持了将近60%的市场份额。不得不说DataDomain的创业是成功的，DataDomain的持续领先是值得骄傲的。DataDomain在创业之初就设置了很强的技术屏障，重复数据删除技术应用的一个很大障碍是如何突破磁盘IO瓶颈。那个时候还没有大容量的SSD盘，只有一些基于
IO调度器 当IO旅行到调度器的时候，发现自己受到的待遇竟然很不一样，有些IO倚仗着特权很快就放行了；有些IO迟迟得不到处理，甚至在有些系统中居然饿死！面对这样的现状，IO显然是很不高兴的，凭什么别人就能被很快送到下一个旅程，自己需要在调度器上耗费青春年华？这里是拼爹的时代，人家出身好，人家是读请求，人家就可以很快得到资源。咱们是写请求，出生贫寒，只能等着，但也不会让你饿死。这就是我们常
块设备层分析无论是经过EXT3文件系统还是块设备文件,最终都要通过writeback机制将数据刷新到磁盘，除非用户在对文件进行读写的时候采用了DirectIO的方式。为了提高性能，文件系统或者是裸设备都会采用Linux的cache机制对数据读写性能进行优化，因此都会采用writeback回写机制将数据写入磁盘。通过上述分析我们已经知道，writeback机制会调用不同底层设备的address_sp
概述大家知道随着磁盘容量的增大，数据在RAID级别的存储可靠性受到了极大的威胁。其最为突出的问题是磁盘重构时间大为增加，对于RAID6而言三块盘坏的几率也大为增加，与此同时，应用性能在磁盘重构时也大为降低。这就是目前传统RAID所遇到的最棘手的问题，很多存储厂商都在想办法解决目前RAID所遇到的问题。针对RAID所遇到的问题，我想基本有两种解决方案，一种就是像当年从RAID5过渡到RAID6一样，
块设备buffer cache机制 在EXT3文件IO踏上新的征程之前，需要介绍一位EXT3文件IO的同伴，他们即将踏上相同的旅程。只不过这位同伴没有经历过EXT3文件系统的精彩，却领略了另外一番略有差别的风情。这位同伴是在块设备写操作时创建诞生的，我们可以称它为块设备IO。在很多应用中都会直接进行块设备操作，我们常用的命令dd就可以进行块设备的读写。例如：dd&n
去年年底的时候买了一本书《兼容ARM9的软核处理器设计》，前一段时间很仔细的进行了阅读，感觉很有参考价值。作者是一位芯片设计工程师，其利用空余时间做了一个很有意思的开源项目，自己采用FPGA实现了一个兼容ARM9处理器的RTL软核。初看到这个想法的时候，我觉得很疯狂，因为想要实现一个ARM9处理器兼容的CPU不是一件容易的事情，处理器内部流水线机制、相关性的处理、各种计算单元的实现，另外还需要去验
数据回写对于EXT3文件系统而言，在绝大多数情况下，IO请求走到page cache之后就认为这个IO处理已经完成了。用户的IO请求被放入Cache之后，用户操作结束。实际上，此时的IO处境非常的危险，如果系统在此时Crash，那么内存中缓存的数据将会彻底丢失。为了保证数据不丢失，需要有一种机制及时的将缓存中的数据同步（回写）到磁盘。对于2.6.23版本的Linux，采用了Pdflush
EXT3文件写操作 如果应用层发起的是一个Word文档的写操作请求，那么通过上述分析，IO会走到sys_write的地方，然后执行file->f_op->write方法。对于EXT3 ，该方法注册的是do_sync_write。Do_sync_write的实现如下：ssize_t do_sync_write(struct file *filp, const char
前言前几天同事提议写一篇文章来仔细分析一下一个IO从创建到消亡的整个过程，我觉得这个想法很好，一个IO从创建到消亡经历了千山万水，从软件到硬件涉及到很多很多的技术。一个看似简单的IO读写操作，其实汇集了从计算机软件技术、硬件技术、电子技术、信号处理等各个方面的内容。所以，我想把IO的一生通过自己的认识把他描述一下，让世人看清在执行一个简单的IO操作究竟汇集了多少的智慧！汇集了工程师、科学家多少的心
Copyright © 2005-2022 51CTO.COM 版权所有 京ICP证060544号
