http://freesource.info/wiki/HCL/ХранениеДанных/NAS History/revisions of FreeSource/HCL/ХранениеДанных/NAS en-us http://freesource.info/wiki/HCL/XranenieDannyx/NAS/show?time=2007-04-21+12%3A06%3A40 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".hcl.xraneniedannyx.nas" href="http://freesource.info/wiki/HCL/XranenieDannyx/NAS&" class="">/HCL&nbsp;/&nbsp;Хранение&nbsp;Данных&nbsp;/&nbsp;NAS</a> за <a href="http://freesource.info/wiki/HCL/XranenieDannyx/NAS?time=2007-04-21+12%3A06%3A40">2007-04-21 12:06:40</a> и <a href="http://freesource.info/wiki/HCL/XranenieDannyx/NAS">2007-04-21 12:12:37</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions"><strong>Our double failure rate is&nbsp;about 5 orders of&nbsp;magnitude worse than that &ndash; the&nbsp;majority of&nbsp;single drive failures are&nbsp;followed by&nbsp;a second drive failure before redundancy is&nbsp;established. This prevents rebuilding the&nbsp;array with a&nbsp;new drive replacing the&nbsp;original failed drive, however you&nbsp;can probably recover most files if&nbsp;you stay in&nbsp;degraded mode and&nbsp;copy the&nbsp;files to&nbsp;a different location.</strong> It&nbsp;isn't that failures are&nbsp;correlated because drives are&nbsp;from the&nbsp;same batch, or&nbsp;the controller is&nbsp;at fault, or&nbsp;the environment is&nbsp;bad (common electrical spike or&nbsp;heat problem). The&nbsp;fault lies with the&nbsp;Linux md&nbsp;driver, which stops rebuilding parity after a&nbsp;drive failure at&nbsp;the first point it&nbsp;encounters a&nbsp;uncorrectable read error on&nbsp;the remaining &#8220;good&#8221; drives. Of&nbsp;course with two&nbsp;drives unavailable, there isn't an&nbsp;unambiguous reconstruction of&nbsp;the bad&nbsp;sector, so&nbsp;it might be&nbsp;best to&nbsp;go to&nbsp;the backups instead of&nbsp;continuing. At&nbsp;least that is&nbsp;the apparently the&nbsp;reason for&nbsp;the decision.</div><br /> <b>Удалено:</b><br /> <div class="deletions">Our&nbsp;double failure rate is&nbsp;about 5 orders of&nbsp;magnitude worse than that &ndash; the&nbsp;majority of&nbsp;single drive failures are&nbsp;followed by&nbsp;a second drive failure before redundancy is&nbsp;established. This prevents rebuilding the&nbsp;array with a&nbsp;new drive replacing the&nbsp;original failed drive, however you&nbsp;can probably recover most files if&nbsp;you stay in&nbsp;degraded mode and&nbsp;copy the&nbsp;files to&nbsp;a different location. It&nbsp;isn't that failures are&nbsp;correlated because drives are&nbsp;from the&nbsp;same batch, or&nbsp;the controller is&nbsp;at fault, or&nbsp;the environment is&nbsp;bad (common electrical spike or&nbsp;heat problem). The&nbsp;fault lies with the&nbsp;Linux md&nbsp;driver, which stops rebuilding parity after a&nbsp;drive failure at&nbsp;the first point it&nbsp;encounters a&nbsp;uncorrectable read error on&nbsp;the remaining &#8220;good&#8221; drives. Of&nbsp;course with two&nbsp;drives unavailable, there isn't an&nbsp;unambiguous reconstruction of&nbsp;the bad&nbsp;sector, so&nbsp;it might be&nbsp;best to&nbsp;go to&nbsp;the backups instead of&nbsp;continuing. At&nbsp;least that is&nbsp;the apparently the&nbsp;reason for&nbsp;the decision.</div></div>