From owner-freebsd-fs@FreeBSD.ORG Fri Jan 20 11:29:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A168106564A for ; Fri, 20 Jan 2012 11:29:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 594BF8FC12 for ; Fri, 20 Jan 2012 11:29:57 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta04.emeryville.ca.mail.comcast.net with comcast id PnUz1i00517UAYkA4nVxBk; Fri, 20 Jan 2012 11:29:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id PnVw1i00M1t3BNj8ZnVx8b; Fri, 20 Jan 2012 11:29:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BAD03102C19; Fri, 20 Jan 2012 03:29:56 -0800 (PST) Date: Fri, 20 Jan 2012 03:29:56 -0800 From: Jeremy Chadwick To: Peter Maloney Message-ID: <20120120112956.GA91803@icarus.home.lan> References: <4F192ADA.5020903@brockmann-consult.de> <20120120090915.GA90876@icarus.home.lan> <4F19359E.6030901@brockmann-consult.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F19359E.6030901@brockmann-consult.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: sanity check: is 9211-8i, on 8.3, with IT firmware still "the one" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 11:29:58 -0000 On Fri, Jan 20, 2012 at 10:36:30AM +0100, Peter Maloney wrote: > On 01/20/2012 10:09 AM, Jeremy Chadwick wrote: > > And media confirmations: > > > > http://www.theverge.com/2012/1/17/2713178/crucial-m4-ssd-firmware-update-fixes-recurring-bsod > > http://www.anandtech.com/show/5308/crucial-to-fix-m4-bsod-issue-in-two-weeks > > http://www.anandtech.com/show/5424/crucial-provides-a-firmware-update-for-m4-to-fix-the-bsod-issue > > > > I've now added Crucial to my SSD brands to avoid (currently OCZ and > > Crucial). Welcome to year 20xx, where nobody actually does quality > > assurance properly. > > What is your problem with OCZ SSDs? Extremely high failure rate compared to other vendors (Intel was the best until the recent 320-series "8MByte capacity" firmware fiasco), and all sorts of performance problems all across the board. Every single time I hear about a new OCZ SSD product, I wait 8-10 weeks and suddenly there's some sort of major bug/quirk found with it. I grew tired of following the trend. I don't know how else to describe it, honestly. If others are cool with it, that's fine -- honest, no argument, everyone should make their own decisions based on what works for them. But for me, it doesn't jibe. What I've been doing for years with a pretty good success rate: before considering any "consumer" product (especially if product reliability matters in your environment, e.g. you don't have HA or 200 spare fail-over boxes available at any moment), visit the Support Forum of the vendor, subcategory relating to the item you're interested in. Spend a few hours over the course of 3-4 weeks reading end-user reports and experiences. Yes, I am well aware that most end-users cannot diagnose problems worth a damn, but it doesn't matter -- all you have to look for is common trends in reports to get a feel for something. If you aren't left with that "warm fuzzy" feeling (SAs here should know what I mean), take note of your reasons and move on to another product. When a colleague (not someone online) asks you "What do you mean you don't like FooProduct?" you can say "here's why". This is what I did before choosing to invest in Intel SSDs for our servers, as well as for my workstation (Windows box) and my home FreeBSD box. I even did the latter with regards to some perl software I wrote for my own purposes. I went looking for a config file parsing perl module that did what I needed. I tried 15 modules. FIFTEEN OF THEM. I began to lose track which ones I tried and why they sucked. So, in the software repo of the program I wrote, I made this file: -rw------- 1 jdc users 4368 Mar 5 2008 horrible_perl_modules.txt Which documented the shortcomings/issues I had with them. A few years later, someone asked me for this program I wrote so I sent them a tarball. The following morning I had a mail from them saying "Oh my god, horrible_perl_modules.txt! I wish more people did write-ups like this in their software explaining why they used ThingA and why Thing[XYZ] didn't work *for this program specifically*!" Yeah well, that's just how I operate. Back to my method -- it's in no way shape or form fail-proof. For example, I have two Intel 320-series SSDs that have not been bit by the "8MByte capacity" bug but I pulled them out of use the INSTANT Intel confirmed its existence and replaced them with either X25-M or 510-series units. I didn't jump on the Intel Cougar Point bandwagon (I waited a year), thus avoided the SATA-related B2 stepping bug (who will remember that in years to come?). But I can't tell you how many times I've sighed and said "dodged that bullet!" It's far from perfect, but it's a hell of a lot better than making a decision based on some biased hardware review site benchmarks, or even word-of-mouth (which matters a lot, but only if the person who's selling you the product has the same belief system you do ;-) ). You have to visit the Support Forums, it's really the only way you'll know of what trouble you might be getting yourself into -- and you can then determine if that risk is worth it or not. If it is, as I said, totally cool. If it isn't, also cool. Whatever works for you! When it comes to products, I don't tolerate vendors' "hey, mistakes happen" behaviour, and (when I can) I speak with my wallet, because at the end of the day that's really the only way to "talk" to a vendor. All this stuff is made by humans, and we're not perfect beings. I accept that. Certain technology today is more reliable than it was 20-25 years ago, while other technology isn't. We've had to make a lot of trade-offs as technology has evolved though, and some (most?) of those I do not agree with. It's all about quality assurance and decent testing or lack thereof. It often shocks me how many companies have QA departments who only test what they're shown/told to test and not actually assure quality. So many QA divisions do not understand the innards of what they're testing; "run this script, look at these numbers" seems to be the modus operandi. We've got it all wrong. Finally, please note: I am in no way shape or form an "Intel fanboy". I use whatever products I choose at the time. I'd rather not cite examples in this mail (it's long enough as is), nor privately, but believe me, I have a list of lots of products, and a shorter list of actual vendors/manufacturers that I avoid. A year from now those lists might be different based on what I witness, discover, or even try. You might even find some of my examples on the web if you look hard enough. For me, it feels like it boils down to one thing: I am a dying breed of system administrator and technician. In today's technology/IT world, the mentality is that everything is expendable, everything will fail (and more importantly don't bother figuring out **why**, just replace it and pretend it didn't happen; solve nothing, bury head in ground). I feel like I'm one of those rare few who was taught skills based on a foundation of KISS principle and actually *solving problems* rather than saying "f-it" and accepting them as "technology is just flaky". I wasn't raised, educated, nor trained to accept that excuse. I guess that's why I consider myself a technophobe; I feel more and more like H.P. Lovecraft every time I have to deal with a bug in, well, anything. Anyway, that's all from me on the matter. I won't be replying past this point; there just isn't much for me to say. (Sorry, I've had a very, VERY long week...) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |