So evaluating cost/usable_GB shows these are infinitely expensive since &quot;usable_GB&quot; = 0<br><br>:-( <br><br><div class="gmail_quote">On Wed, Jan 6, 2010 at 3:54 PM, William Fragakis <span dir="ltr">&lt;<a href="mailto:william@fragakis.com">william@fragakis.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16822148337" target="_blank">http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16822148337</a><br>

<br>
sort by lowest rating first. Lots of interesting comments about these<br>
drives in RAID configs. Not that it would help you now but maybe it<br>
feels better to know you aren&#39;t alone.<br>
<br>
wf<br>
<div><div></div><div class="h5"><br>
On Wed, 2010-01-06 at 15:09 -0500, Brian W. Neu wrote:<br>
&gt; I have a graphic design client with a 2U server running Fedora 11 and<br>
&gt; now 12 which is at a colo handling their backups.  The server has 8<br>
&gt; drives with Linux md raids &amp; LVM on top of them.  The primary<br>
&gt; filesystems are ext4 and there is/was an LVM swap space.<br>
&gt;<br>
&gt; I&#39;ve had an absolutely awful experience with these Seagate 1.5 TB<br>
&gt; drives, returning 10 out of the original 14 due to the ever increasing<br>
&gt; SMART &quot;Reallocated_Sector_Ct&quot; due to bad blocks.  The server that the<br>
&gt; client has at their office has a 3ware 9650(I think) that has done a<br>
&gt; great job of handling the bad blocks from this same batch of drives<br>
&gt; and sending email notifications of one of the drives that grew more<br>
&gt; and more bad blocks.  This 2U though is obviously pure software raid,<br>
&gt; and it has started locking up.<br>
&gt;<br>
&gt; As a stabilizing measure, I&#39;ve disable the swap space, hoping the<br>
&gt; lockups were caused by failure to read/write from swap.  I have yet to<br>
&gt; let the server run over time and assess if this was successful.<br>
&gt;<br>
&gt; However, I&#39;m doing a lot of reading today on how md &amp; LVM handle bad<br>
&gt; blocks and I&#39;m really shocked.  I found this article (which may be<br>
&gt; outdated) which claimed that md relies heavily on the firmware of the<br>
&gt; disk to handle these problems and when rebuilding an array there are<br>
&gt; no &quot;common sense&quot; integrity checks to assure that the right data is<br>
&gt; reincorporated back into the healthy array.  Then I&#39;ve read more and<br>
&gt; more articles about drives that were silently corrupting data.  It&#39;s<br>
&gt; turned my stomach.  Btrfs isn&#39;t ready for a this, even though RAID5<br>
&gt; was very recently incorporated.  And I don&#39;t see btrfs becoming a<br>
&gt; production stable file system until 2011 at the earliest.<br>
&gt;<br>
&gt; Am I totally wrong about suspecting bad blocks for causing the<br>
&gt; lock-ups?  (syslog records nothing)<br>
&gt; Can md RAID be trusted with flaky drives?<br>
&gt; If it&#39;s the drives, then other than installing OpenSolaris and ZFS,<br>
&gt; how to I make this server reliable?<br>
&gt; Any experiences with defeating mysterious lock-ups?<br>
&gt;<br>
&gt; Thanks!<br>
&gt;<br>
&gt; ------------------------------SMART Data-----------------------------<br>
&gt; [root@victory3 ~]# for letter in a b c d e f g h ; do echo /dev/sd<br>
&gt; $letter; smartctl --all /dev/sd$letter |grep Reallocated_Sector_Ct;<br>
&gt; done<br>
&gt; /dev/sda<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       8<br>
&gt; /dev/sdb<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       1<br>
&gt; /dev/sdc<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       0<br>
&gt; /dev/sdd<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       0<br>
&gt; /dev/sde<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       1<br>
&gt; /dev/sdf<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       0<br>
&gt; /dev/sdg<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       1<br>
&gt; /dev/sdh<br>
&gt;   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail<br>
&gt; Always       -       0<br>
</div></div>&gt; _______________________________________________<br>
&gt; Ale mailing list<br>
&gt; <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
&gt; <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
&gt; See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt; <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness         <br><br>