So evaluating cost/usable_GB shows these are infinitely expensive since "usable_GB" = 0<br><br>:-( <br><br><div class="gmail_quote">On Wed, Jan 6, 2010 at 3:54 PM, William Fragakis <span dir="ltr"><<a href="mailto:william@fragakis.com">william@fragakis.com</a>></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'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>
> I have a graphic design client with a 2U server running Fedora 11 and<br>
> now 12 which is at a colo handling their backups. The server has 8<br>
> drives with Linux md raids & LVM on top of them. The primary<br>
> filesystems are ext4 and there is/was an LVM swap space.<br>
><br>
> I've had an absolutely awful experience with these Seagate 1.5 TB<br>
> drives, returning 10 out of the original 14 due to the ever increasing<br>
> SMART "Reallocated_Sector_Ct" due to bad blocks. The server that the<br>
> client has at their office has a 3ware 9650(I think) that has done a<br>
> great job of handling the bad blocks from this same batch of drives<br>
> and sending email notifications of one of the drives that grew more<br>
> and more bad blocks. This 2U though is obviously pure software raid,<br>
> and it has started locking up.<br>
><br>
> As a stabilizing measure, I've disable the swap space, hoping the<br>
> lockups were caused by failure to read/write from swap. I have yet to<br>
> let the server run over time and assess if this was successful.<br>
><br>
> However, I'm doing a lot of reading today on how md & LVM handle bad<br>
> blocks and I'm really shocked. I found this article (which may be<br>
> outdated) which claimed that md relies heavily on the firmware of the<br>
> disk to handle these problems and when rebuilding an array there are<br>
> no "common sense" integrity checks to assure that the right data is<br>
> reincorporated back into the healthy array. Then I've read more and<br>
> more articles about drives that were silently corrupting data. It's<br>
> turned my stomach. Btrfs isn't ready for a this, even though RAID5<br>
> was very recently incorporated. And I don't see btrfs becoming a<br>
> production stable file system until 2011 at the earliest.<br>
><br>
> Am I totally wrong about suspecting bad blocks for causing the<br>
> lock-ups? (syslog records nothing)<br>
> Can md RAID be trusted with flaky drives?<br>
> If it's the drives, then other than installing OpenSolaris and ZFS,<br>
> how to I make this server reliable?<br>
> Any experiences with defeating mysterious lock-ups?<br>
><br>
> Thanks!<br>
><br>
> ------------------------------SMART Data-----------------------------<br>
> [root@victory3 ~]# for letter in a b c d e f g h ; do echo /dev/sd<br>
> $letter; smartctl --all /dev/sd$letter |grep Reallocated_Sector_Ct;<br>
> done<br>
> /dev/sda<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 8<br>
> /dev/sdb<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 1<br>
> /dev/sdc<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 0<br>
> /dev/sdd<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 0<br>
> /dev/sde<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 1<br>
> /dev/sdf<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 0<br>
> /dev/sdg<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 1<br>
> /dev/sdh<br>
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail<br>
> Always - 0<br>
</div></div>> _______________________________________________<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>
<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>