<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/knight_rain</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; knight_rain]]></copyright><item><title><![CDATA[RAID5 Write Hole]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6191205</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6191205</guid><author>knight_rain</author><pubDate>Thu, 17 Feb 2011 12:15:00 +0800</pubDate><description><![CDATA[最近一段时间又重新接触了RAID，这次是关于RAID5 Write Hole的问题。这里把我对这个问题的理解描述一下。
Write Hole是RAID5的一个重大缺陷，这个问题在我以前的日志中已经提到过，但是只是作为解释代码的引子，而没有强调它的重要性。要了解这个问题，首先要对RAID5的rcw和rmw有一定了解。我以前的文章（RAID-5（五）rmw与rcw ）已经解释过这些动作。为了方便说明，假设有一个5个盘的RAID5（为什么是5个盘？因为rmw）。]]></description><category></category></item><item><title><![CDATA[MD（七）In_sync标志与resync]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6188673</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6188673</guid><author>knight_rain</author><pubDate>Wed, 16 Feb 2011 17:44:00 +0800</pubDate><description><![CDATA[关于mddev->in_sync的作用我一直只是一知半解，前段时间终于有机会将它的用法重新理解了。原来它是出于数据安全考虑的。]]></description><category></category></item><item><title><![CDATA[MD（六）小议superblock]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6185679</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6185679</guid><author>knight_rain</author><pubDate>Tue, 15 Feb 2011 12:27:00 +0800</pubDate><description><![CDATA[Superblock通常总是用来保存一些配置信息，MD中的superblock也不例外，通过看md_p.h中的mdp_superblock_s的定义大致就能了解其内容。MD的Superblock保存的信息主要包括：（1）基本信息(Constant generic information) ：主从设备号，UUID，RAID级，size，设备数量等；（2）一般状态信息(Generic state information)：包括一般MD运行的统计信息；（3）Personality information：看上去似]]></description><category></category></item><item><title><![CDATA[MD（五）MD中的线程]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6183689</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6183689</guid><author>knight_rain</author><pubDate>Mon, 14 Feb 2011 12:30:00 +0800</pubDate><description><![CDATA[实际上MD中线程的调度都是植根于linux中的调度，我这里为什么要单独拿出来讨论讨论？因为我觉得MD的线程写法挺有意思，让我受益匪浅。]]></description><category></category></item><item><title><![CDATA[MD（四）进入syncd内部]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6167888</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6167888</guid><author>knight_rain</author><pubDate>Fri, 28 Jan 2011 12:30:00 +0800</pubDate><description><![CDATA[看md_check_recovery中注册syncd的代码，就能知道syncd执行的动作就是函数md_do_sync。这个函数也不是省油的灯！]]></description><category></category></item><item><title><![CDATA[MD（三）resync和recovery的调度（下）]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6167056</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6167056</guid><author>knight_rain</author><pubDate>Thu, 27 Jan 2011 17:46:00 +0800</pubDate><description><![CDATA[说完启动再来看它的结束。同样是在md_check_recovery中，但我们会发现处理结束的代码处于处理启动的代码之前。其中的逻辑其实也很好理解，无非就是先处理已经启动的线程，但是由于我在阅读这部分代码时花了点时间，所以多罗嗦几句。实际上，光是md_check_recovery中的代码实际上并没有完全结束resync和recovery，只是结束了syncd，从这段代码注释中的“double check”就可以看出来。我们还是先看看syncd是如何结束的，再看resync和recovery如何停止。结束syn]]></description><category></category></item><item><title><![CDATA[MD（三）resync和recovery的调度（上）]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6165216</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6165216</guid><author>knight_rain</author><pubDate>Wed, 26 Jan 2011 17:17:00 +0800</pubDate><description><![CDATA[说到调度，一般都是说进程或者线程调度，这里也不例外，因为resync和recovery都是由一个后台的MD工作线程在执行的，我们且称之为syncd。不再象2.4那样在RAID启动时为其注册一个syncd，如果没有工作就一直休眠，有resync的需要时就起来工作，2.6内核是在有resync需要时才注册syncd，在resync完毕就将其注销；2.6也不象2.4那样将resync线程与recovery线程分开，而是在需要时注册一个线程需要做resync就做resync，需要recovery就做recovery]]></description><category></category></item><item><title><![CDATA[MD（二）resync和recovery概论]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6164563</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6164563</guid><author>knight_rain</author><pubDate>Wed, 26 Jan 2011 12:14:00 +0800</pubDate><description><![CDATA[到底什么是resync和recovery？虽然我们在RAID-5中讨论了它们的作用，但是它们并不只存在于RAID-5中，所以很多通用的操作被提到了MD中来。

]]></description><category></category></item><item><title><![CDATA[MD（一）数据结构]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6162768</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6162768</guid><author>knight_rain</author><pubDate>Tue, 25 Jan 2011 12:37:00 +0800</pubDate><description><![CDATA[要看MD的数据结构，那就得看md_k.h了。这里有最主要的三个结构定义：mddev_s这是MD本身的结构；mdk_rdev_s这是对应于MD中子设备的结构；mdk_personality这是个有函数指针组成的结构，各函数交由各RAID级自己去实现。

]]></description><category></category></item><item><title><![CDATA[Multiple Devices]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6161693</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6161693</guid><author>knight_rain</author><pubDate>Mon, 24 Jan 2011 17:37:00 +0800</pubDate><description><![CDATA[RAID-5中我们已经多次提到MD的作用，MD提供了很多控制功能。请容忍我刚想到的一个比喻，MD就像一个DVD机，而各级RAID就像各种DVD光盘，DVD机播放的内容由放在里面DVD光盘决定，没有光盘，DVD机也不能起作用，没有DVD机，我们也无法享受光盘中的电影了；正是有了DVD机，我们不仅可以装入不同的光盘，而且还可以快进、快退，调节音量…等等。正因为这样，我们知道DVD机就比DVD光盘要复杂，同样的道理，MD相对于RAID-5而言又更复杂一些，我们可以看md.c有5000多行，是RAID-5的两倍多。]]></description><category></category></item><item><title><![CDATA[RAID-5（十三）其它]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6160534</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6160534</guid><author>knight_rain</author><pubDate>Mon, 24 Jan 2011 09:31:00 +0800</pubDate><description><![CDATA[前面几篇林林总总，从RAID-5原理，到错误，失效处理，主要还是围绕数据处理的方方面面来说的，但是RAID-5要能正常使用，没有一些控制函数的辅助是不可能的。我所说的这些控制函数可以在raid5.c快要结束的地方，在raid5_personality这个结构中找到他们的名字。]]></description><category></category></item><item><title><![CDATA[RAID-5（十二）resync与recovery ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6156705</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6156705</guid><author>knight_rain</author><pubDate>Fri, 21 Jan 2011 12:28:00 +0800</pubDate><description><![CDATA[但是我们有必要知道resync和recovery在RAID-5中的作用。我们知道RAID-5在写数据时需要计算Parity，更重要的是如果做的是 rmw，那就要求Parity在写之前必须已经正确的写到下层设备中。]]></description><category></category></item><item><title><![CDATA[RAID-5（十一）stripe_head的管理 ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6155322</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6155322</guid><author>knight_rain</author><pubDate>Thu, 20 Jan 2011 16:54:00 +0800</pubDate><description><![CDATA[前面其实我们已经看到了一些stripe_head管理的结构，比如handle_list，delayed_list。我们知道，stripe_head是在RAID-5开始运行的时候开辟的缓冲区，这是个有限的资源，那么除了要在数据处理过程中需要调度以外，还需要一套完整的机制去使得这些有限的资源能够满足数据情求的处理所需。 ]]></description><category></category></item><item><title><![CDATA[RAID-5(十)raid5d线程 ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6154162</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6154162</guid><author>knight_rain</author><pubDate>Thu, 20 Jan 2011 10:07:00 +0800</pubDate><description><![CDATA[raid5d是RAID-5的守护线程，我们知道make_request将数据做了初步处理以后就结束了，那么这个stripe_head的后续处理权就都交到了raid5d的手里。]]></description><category></category></item><item><title><![CDATA[RAID-5（九）handle_stripe ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6153145</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6153145</guid><author>knight_rain</author><pubDate>Wed, 19 Jan 2011 17:15:00 +0800</pubDate><description><![CDATA[这个函数就像RAID-5数据处理的核心。前面我们所讲的一些操作如rmw和rcw，BSR，延迟写大部分的相关代码都能在handle_stripe中找到。这个函数有近500行的代码，可见这个函数要处理的内容有多么丰富，弄懂了这个函数，基本上就能理解linux中RAID-5数据是如何处理的。]]></description><category></category></item><item><title><![CDATA[RAID-5（八）失效处理]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6152054</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6152054</guid><author>knight_rain</author><pubDate>Wed, 19 Jan 2011 12:07:00 +0800</pubDate><description><![CDATA[所谓失效（failed），我这里指的是RAID-5下层设备无法正常工作。比方说，下层的n个设备中有两个设备发生了故障，那么在这两个设备上的数据将无法再读写，因为你无法直接读取盘上的数据，也无法通过Parity将这些数据计算出来，同时，写的时候也无法提供足够数据来计算Parity。也就是说，RAID-5已经无法正常工作。]]></description><category></category></item><item><title><![CDATA[RAID-5（七）Error处理 ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6149356</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6149356</guid><author>knight_rain</author><pubDate>Tue, 18 Jan 2011 12:28:00 +0800</pubDate><description><![CDATA[RAID-5能提供一定程度的可靠性，也就是说能容忍一定程度的错误，那么在I/O中出现错误的时候， RAID-5时如何处理的呢?]]></description><category></category></item><item><title><![CDATA[RAID-5（六）延迟写 ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6147477</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6147477</guid><author>knight_rain</author><pubDate>Mon, 17 Jan 2011 17:49:00 +0800</pubDate><description><![CDATA[延迟写是RAID-5中提高I/O吞吐率的一种重要的方法。延迟写（delay write），顾名思义就是在make_request将写请求加入到stripe_head中以后，并不急于启动写处理（rmw或rcw），而是等一段时间，看是不是有后续的写请求也会被加入到这个stripe_head中。最好的情况就是后续加入的写请求填满了所有的数据dev，这样我们就不需要任何额外读就可以计算新Parity。这在顺序写（sequential WRITE）的情况下能带来很好的效果，而实践中很多情况都是顺序写的。别看前面的一些]]></description><category></category></item><item><title><![CDATA[RAID-5（五）rmw与rcw ]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6146549</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6146549</guid><author>knight_rain</author><pubDate>Mon, 17 Jan 2011 12:18:00 +0800</pubDate><description><![CDATA[对于写请求的处理，可以分为read_modify_write（rmw）和read_reconstruct_write（rcw）。由于前面介绍一次简单的写处理时假设了sh只有一个dev需要写，于是就按照rmw的过程来介绍了。但事实上，一个sh中可能有多个dev要写，这就产生了一个问题：如何能减少这次处理的所需的预读操作？正如前面描述的，为了计算Parity，一些预读处理是不可避免的。所以，区分rmw和rcw就是为了使这些预读尽可能少。]]></description><category></category></item><item><title><![CDATA[RAID-5（四）make_request]]></title><link>https://blog.youkuaiyun.com/knight_rain/article/details/6139545</link><guid>https://blog.youkuaiyun.com/knight_rain/article/details/6139545</guid><author>knight_rain</author><pubDate>Fri, 14 Jan 2011 17:02:00 +0800</pubDate><description><![CDATA[make_request是RAID-5数据路径的源头，正如我们前面对读写简单叙述中提到的，make_request就是取出stripe_head并将bio插入相应的dev链表，最后对stripe_head做第一轮处理。但我们看make_request的代码，并不是就这么简单的，它还有一些特殊的情况需要处理。]]></description><category></category></item></channel></rss>