From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E33311381F3 for ; Mon, 15 Jul 2013 12:20:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 339DBE09D5; Mon, 15 Jul 2013 12:19:59 +0000 (UTC) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CF446E0898 for ; Mon, 15 Jul 2013 12:19:57 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id q56so10167439wes.31 for ; Mon, 15 Jul 2013 05:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=oKd9L4y73IZb/4lP8Gki0sjty8Sj0wRujyN1rdv8nUs=; b=c4suh6piviJ+M53NLC5x6DhFE1Sf3Y0TKoYfi+ENYcuPPq1YP2LI8ZAMDOF/zvtXhJ 3uAvFcG/2/MY59IEkuy0BGHQCYB6QunVMbdc/sI42yJpto11JKPOb6eYv4w24/epVW4X ka8Er2uvIZJmBKPnlXWBjgLE/DQ+FVvPp7/6+4GLGHaJnfQqUfOj40RiGIv8SrjWn2a1 0r0pkYaXGqS9pzYU5d/QadL+OErEcQYnYyq80VpIegsvd8xQVH8D7VIy+H73alZ/+D6w NG6eynpFbU9q6+YtMvte/DQoazZ+Qh6gveYv1GBo07YvsYniRox6KBXViv6/FsAPKNPg prMA== X-Received: by 10.180.38.102 with SMTP id f6mr8679838wik.12.1373890796338; Mon, 15 Jul 2013 05:19:56 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id fb2sm20538269wic.4.2013.07.15.05.19.54 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 05:19:55 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] hp H222 SAS controller Date: Mon, 15 Jul 2013 08:39:14 +0100 User-Agent: KMail/1.13.7 (Linux/3.8.13-gentoo; KDE/4.10.4; x86_64; ; ) References: <51D33059.5070508@xunil.at> <51DAE18C.2010804@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9544999.NGHqNzoIP3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201307150839.34368.michaelkintzios@gmail.com> X-Archives-Salt: 851a275a-2e84-4164-b363-53c10ef974ec X-Archives-Hash: 387cf7e208d876e259416699085d48ae --nextPart9544999.NGHqNzoIP3 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 14 Jul 2013 23:35:50 Paul Hartman wrote: > On Mon, Jul 8, 2013 at 10:58 AM, Alan McKinnon = =20 wrote: > > On 08/07/2013 17:39, Paul Hartman wrote: > >> On Thu, Jul 4, 2013 at 9:04 PM, Paul Hartman > >>=20 > >> wrote: > >>> ST4000DM000 > >>=20 > >> As a side-note these two Seagate 4TB "Desktop" edition drives I bought > >> already, after about than 100 hours of power-on usage, both drives > >> have each encountered dozens of unreadable sectors so far. I was able > >> to correct them (force reallocation) using hdparm... So it should be > >> "fixed", and I'm reading that this is "normal" with newer drives and > >> "don't worry about it", but I'm still coming from the time when 1 bad > >> sector =3D red alert, replace the drive ASAP. I guess I will need to > >> monitor and see if it gets worse. > >=20 > > Way back when in the bad old days of drives measured in 100s of megs, > > you'd get a few bad sectors now and then, and would have to mark them as > > faulty. This didn't bother us then much > >=20 > > Nowadays we have drives that are 8,000 bigger than that so all other > > things being equal we'd expect sectors to fail 8,000 time more (more > > being a very fuzzy concept, and I know full well I'm using it loosely := =2D) > > ) > >=20 > > Our drives nowadays also have smart firmware, something we had to > > introduce when CHS no longer cut it, this lead to sector failures being > > somewhat "invisible" leaving us with the happy delusion that drives were > > vastly reliable etc etc etc. But you know all this. > >=20 > > A mere few dozen failures in the first 100 hours is a failure rate of > > (Alan whips out the trust sci calculator) 4.8E-6%. Pretty damn > > spectacular if you ask me and WELL within probabilities. > >=20 > > There is likely nothing wrong with your drives. If they are faulty, it's > > highly likely a systemic manufacturing fault of the mechanicals (servo > > systems, motor bearing etc) > >=20 > > You do realize that modern hard drives have for the longest time been up > > there in the Top X list of Most Reliable Devices Made By Mankind Ever? >=20 > An update: the Seagate drives have both continued to spit more > unrecoverable errors and find more and more bad sectors. Including > some end-to-end errors indicated as critical "FAILING NOW" status in > SMART. From what I have read that error means the drive's internal > cache did not match the data written to disk, which seems like a > serious flaw. The threshold is 1 which means if it happens at all, the > drive should be replaced. It has happened half a dozen times on each > disk so far (but not at the exact same time, so I don't think it is a > host controller problem -- and other disks on the same controller and > cable have had no issues). They have also been disconnecting and > resetting randomly, sometimes requiring me to pull the drive and > reinsert it into the enclosure to make it reappear. It happens even > after I disabled APM, so I know it isn't a spin-down/idle timeout > thing. Temperatures are actually very good (low 30's) so they are not > overheating. >=20 > I think I will try to trade them in to Seagate for a new pair under > warranty replacement. And then probably try to sell the replacements > and be rid of them. >=20 > Meanwhile, during that experiment, I bought 2 brand new Western > Digital Red 3TB drives last week. No problems in SMART testing or > creating LVM/RAID/Filesystems. I have now been running the destructive > write/read badblocks tests for 24+ hours and they have been perfect so > far, exactly 0 errors. They are more expensive (3TB for the same price > as the 4TB seagate) and slightly slower read/write speed (150MB/sec > peak vs 170MB/sec peak), but I value reliability over all other > factors. >=20 > These Seagate drives must have some kind of manufacturing defect, or > perhaps were damaged in shipping... UPS have been known to treat > packages like a football! I've been watching this thread with interest, because I've been trying to f= ind=20 out which HDD I should be buying for a new PC. For every person reporting= =20 problematic Seagates there's another person complaining about Western Digit= al=20 being too noisy, failing, or in the case of the black versions, far too=20 expensive. Amidst all the anecdotal aphorisms against one or the other manufacturer, I= =20 saw mentioned that the likelihood of failure doubles up when you go from 1T= B=20 to 2 TB. If true, I guess that the 3TB would have fewer failures than 4TB= =20 drive. =46or what it's worth I have had a number of Seagates failing on me, but si= nce=20 this was in the 90's. On my laptop a Seagate Momentus 7200.4 (ST9500420ASG= )=20 is running fine for the last 3.5 years so, I was thinking of taking a punt = on=20 a 'Seagate Barracuda 3.5 inch 2TB 7200 RPM 64MB 6GB/S Internal SATA'. But= =20 what you're mentioning here gives me cause to pause. =2D-=20 Regards, Mick --nextPart9544999.NGHqNzoIP3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABAgAGBQJR46c2AAoJELAdA+zwE4YegeUIAIWQg3YSRRWy/rd+47PYGYdT pS/Pvk5rDD6qTFxRpKLvQdZfcnQV6E0aw57F4WP7AvyfhforZrVmqvREq2Z4sEPU GG/zXMkGvEe1Zvj3q2L6ja69ZruLrw98FVgnmqLRc6+lha7RhHzTyJjxfz9DgS44 FSpRKBrcdq6Qw7GGeJ22+weFq4941tX54nsoKeBZGX2qvc0N5KyCj1vLGA2DurF0 lnl/pLNk1tJWdDUOATqLmG527b6aLdnA47o7nVYnr3PRhfbPFS0O6k4c5KyHK7eb mPGMA7ONKLc9NcZFueUdT+lKw5C7vHvWTqIHbJmDMLyAY/daRrRBitbwAR3Y2Mg= =SXwL -----END PGP SIGNATURE----- --nextPart9544999.NGHqNzoIP3--