UhClem

With 20+ data drives, and upgrading from one-parity to two-parity, there could be a prior/intervening performance bottleneck. Do you have sufficient (single-core/thread) CPU power? I.e., can you generate enough parity data (fast enough) to justify/validate your stated question? -- "If you push something hard enough, it will fall over."

It looks like you are going in a very sub-optimal direction. You are putting 2 x 550 MB/sec SSDs (860 evo) onto a PCIe v2 x1 (ASM1061) interface (max 350-400 MB/sec total). Why not use 2 of these mSata-to-Sata adapters [ https://www.amazon.com/Sabrent-2-5-Inch-Aluminum-Enclosure-EC-MSSA/dp/B01MS6669V or https://www.amazon.com/ELUTENG-Enclosure-3050mm-Adapter-Compatible/dp/B07258BJJF ] for your mSata SSDs, connecting them to 2 of your Mobo's Sata ports (for full Sata3/6Gbps speed), and get any ASM1061/2-port card for the two "replaced" Mobo-port HDDs. Surely, you can find a place to Velcro (or duct tape) the two adapter-ed mSata's, and deal with the added cables. (It's a computer, not jewelry--so Function >> Form ...kluges are cool.)

Well, that "Amazon page" is, of course, the responsibility of the seller, GoHardDrive. Are they incompetent, or dishonest? [Remember, drives are their specialty--they should be held accountable for correctness.] Yes. From a 4 yrs ago press release [Link], [ That SM863 link on AMZN is also sold by GoHardDrive.] I have no evidence, or direct experience, but my gut tells me to question their integrity. Keep in mind that, while I (and probably you) am (are) not able to modify/reset SMART data, it is definitely possible. A perusal of Google results for <<goharddrive honest>> is enlightening (though not ALL bad). Who did you buy from on ebay? Good luck with your new toys.

But, is newer actually better? Is there really any "upside" to choosing 4kn (vs 512e)? There is (at least) one actual "downside" -- when the drive(s) purchased today are ultimately re-purposed, the 512e drives are guaranteed compatible (by the ATA specifications). I've been pondering this 512e vs 4kn thing, and the above is my current "state of mind". What am I missing?

That is my understanding -- based on reading/research (no hands-on experience) -- seems to have been spurts of interest/discussion over at forums.servethehome.com. Note: The very important point is that it is known to work ONLY on S2600 boards (possibly a few other Intel server boards). It is a LSI 2308-based board, but Intel has locked its interoperability, ... but not the general functionality. Need?? I don't know, but considering that, even if they already had IT firmware, it's probably old version and might benefit from an update. The important thing is that it looks like updating to (newer) IT firmware is possible, and follows the standard Modus Operandi-- see [Link] (posts by "Marsh", toward the end). Don't look a gift horse in the mouth. [Or, better, "Trust, but verify."] Also, [Intel doc for the board] No promises, but there's even a chance it is PCIe v3.0.

http://www.madepc.com/Intel-8-Ports-SAS-RAID-Controller-PCI-Express-2-0-p/301005654-08.htm Price: $8.14 each - Free shipping (Geez, I can't even use this, but I "want" to buy one at this price---must resist ...) (very reliable seller - but can use AmazonPAY if u want) Manufacturer:Intel Corp Mfr.Part Number:RMS25KB080 MadePC SKU:301005654-08 Condition:New Notes:RMS25KB080, 1 Year Warranty, Hight Profile Bracket, Low Profile Bracket Thought: Folks using other LSI-based cards in their S2600's might want to buy these, and free-up/repurpose their "unlocked" cards. win-win

Better yet, get your tech info first-hand: From LSI (white paper on Databolt) [to borrow an old Unix joke: "Use the source, Luke."] This paper also gives a good overview on expanders. Oh, as for the queried controller in the OP ... if Chiney-fakes weren't bad enough, this one must also be avoided on moral grounds. To make such a denigrating reference/inference on the most innovative and impactful OS is pure blasphemy ... Unicaca ... feh!!!!

Thank you for your summary. (I hadn't bothered -- once I saw the CERN paper was one of the references, I lost all confidence ["...baby...bath water." ]). A+ for you. I'm surprised it was even published ... but I appreciate CERN's openness (or was it ignorance?). Personally, I would be totally embarrassed to admit that I had purchased, and deployed into production, 600 RAID controllers and 3000 drives, without first getting 3-4 controllers & 15-20 drives and beating the sh*t out of it all for a week or two (and not just 2GB every 2 hours). But, why should they care ... it's just the(ir) taxpayers' money. [And, in 2006, that probably represented ~US$750,000+ (in 2006 euros).] Did they even get competitive bids? [Make that $1M+] Those data path issues were formally addressed in 2007 when they were added to SMART, but had probably been implemented in drive firmware even earlier by the competent manufacturer(s). --UhClem (almost accepted a job offer from CERN in 1968 ... then my draft deferment came through)

Not that CERN "study" again. c3, did you actually read it ? (not just casually) I invite everyone who has participated in this thread to read it (this version is only 7 pages). See if you can find the numerous flaws in his presentation, and conclusions. Extra credit if you deduce the overall premise/motivation. -- UhClem "Gird your grid for a big one ..."

Please convince me (not being argumentative--I'm sincere!). But, to convince me, you'll need a rigorous presentation, using a valid evidence trail. I appreciate your time/effort. Oh yeah, I do recall seeing that, but always in a casual perusal of one of HGST Ultrastar manuals. Thanks for pointing it out to me in the context of a technical discussion, where I'm motivated to dig into it deeper. My first two minutes of digging has already added a few crumbs of new knowledge to my quest to understand the factory/low-level formatting. Agreed ... since the reduction in drive data capacity when going from 4k sectors to (4k+128) sectors is only 3.5%. I believe they do it so you'll buy (the same # of) (much!) more expensive drives. After all, these are the same execs/bureaucrats that spent ~$500Billion on the Y2K scam; why not soak them for a measly extra $5-10B to protect their data (and cover their hiney). Remember, fear, and lawyers, (and fear of lawyers) are great motivators in such finagles. Presently, I'm about 75% serious in the above. But I'm waiting, and very open, to be convinced otherwise. -- UhClem

Untrue! Rather than (try to) get into the theory of error detection and correction [at the level implemented in HDD firmware] (which I doubt ANY reader of this forum is competent to do--I'm surely not!), consider this: If a collision was easy (Hell! forget easy; if a collision was even *possible*), hard drives would only be used by careless hobbyists. (Regarding HDDs) I agree with RobJ (and I've written the same 2+ times on this board in the last few years): Note that few is pretty large (8-12+, I think) for a 512/4096-byte sector. And the firmware will make many retry attempts to get a good read; I've seen evidence of 20. And then the OS driver will usually retry several times. Only then does the OS throw a UCE. As for johnnie.black's original experience/report, I'm intrigued/disturbed. Whose controller does Sandisk use? [ Added: Note in the original post, there appear (I don't know unRAID's logging methodology) to have been 26 UCEs Reported by this drive (over its lifetime, prior to 12Mar2017:2253 (that is SMART code 187) and 1 Reallocated sector (SMART code 5; that "somebody" is labeling `retired'). Do I assume, because of the way this logging is done, and the way that you are monitoring it, that you *know* that all of this bogosity (the 26 & 1) happened very recently? And that there was no sign of it in dmesg etc? If so, and if this SSD's firmware implements SMART correctly, where were those 26 errors REPORTED? As I understand, there is a different category of SMART error for logging "implicit" errors (from self-diagnosis, Trim, etc.) that can't be "reported". Speaking of which ... what does a "smartctl -a /dev/sdX" show in the Error_Log? Or, does Sandisk (mis)behave like Western Digital and not bother to Log Errors? (Hitachi/HGST has spoiled me--they do [almost] everything right.) (Hey, who remembers the Samsung fiasco when they had a serious firmware bug in the F4 series (HD204, etc.)? As if the bug wasn't bad enough, when they released a fixed firmware, they HAD NOT CHANGED THE FIRMWARE VERSION/REVISION # ] -- UhClem

Those ARE the bad blocks, in more detail and only the last 5. UNC is short for UNCorrectable, so "Error: UNC at LBA = 0x0fffffff = 268435455" roughly means "bad block at 268435455". Not this time ... Look at the fuller "picture"-- first, always be a little suspicious of numbers that are "all ones" (ie, 0x0fffffff); then look carefully at the preceding commands in the error log for the conclusive clue. "The devil is in the details." --UhClem

tr = "translate" transliterate [cf: Unix man page, 1970s]

Thanks. But I must ... Murphy is a master criminal--and, even when you're good/lucky enough to catch him, he never goes to jail.

There are many reasons for a disk to perform below its specs. But there are hardly any reasons for a disk to perform above its specs, especially by the amount indicated in your report. Not only that, but it is not just the one disk, but both! (The other disk is only 20-25% over spec [vs ~30% for the quoted one].) Additionally, both 3rd passes are notably faster than the average for all 3 passes. Far-fetched as it seems, I've got to ask ... Did you set the system clock (back by about 1 hour) sometime Saturday morning? [via date -s XXX]

Those odds are 0.00 (at least, with Powerball, you have > 0 odds ) The buffer cache keeps the most recent data. Doesn't preclear.sh do strictly increasing-LBA sequential operations (for all buffered I/O) ? [Regardless, as you noted, (even in the most optimally perverse case,) a few "fast" GB out of 3TB would have immeasurable negligible effect.]

Your disks looked perfectly normal to me. Except, maybe, the Read performance--it's too fast . Specifically, the Pre Read Time speed. 209 MB/s as an AVERAGE for the entire drive, is fantastic. I'd have expected something closer to 150-160. "There's something going on here, but I don't know what it is ..." Ideas?

There are numerous reports (on other forums' MicroServer threads [homeservershow.com & overclockers.com.au]) of people successfully installing one or another unlocked ("modified") BIOS (initially intended, and used, on the N36L/N40L) on the new N54L. If you stay with the stock BIOS, SATA ports 4 & 5 are locked in IDE mode and limited to SATA I speeds. Also they are incapable of hot-swap usage and port-multiplier controllability (both of which require the port to be in AHCI mode). Just Do It!!

Note that I "stuck my nose in" here because it seemed like both RobJ and JoeL agreed that the time added to the script/cycle run (by the "feature" you described) was of some significance. It was only in the process of composing my previous (ie 2nd) response that I made an effort to quantify it (~0.5%). I'll bet neither of you realized it was so negligible--if I had, I wouldn't have bothered ... but then, look at all the fun we'd have missed. I still contend that a more apt rationale for adding the "feature" would be "I didn't want the drive to get bored." [Those 6 seeks every ~20 seconds are not going to affect the temperature. Here's a little experiment I just did. I had a spinning, but idle, drive at 30C. I did 5 minutes worth of flat-out reading (similar to your pre-read w/o the dance). When it finished, the drive was at 31C. I let the drive rest for 15 minutes; back to 30C. Then did 5 minutes of flat-out seeking (seektest); when finished, the drive was at 35C (that was ~1400 seeks per 20 sec.).] No, it does not. In even the most perverse case, where each and every seek resulted in a read-retry, it would not even have doubled that overhead. Ie, instead of ~0.5% extra, it would have been <~1.0%. How is that going to "show in the speed of the preclear process"? Also, it does not show in a SMART report. (In anticipation of a misguided reply ... Seek_Error_Rate is not only undocumented, but also looks to not even be "implemented" on most drives (only Seagate)) Huh? 995/1000 is a fraction, right? Seriously, any measurable speed difference was not caused in any way by the dislocation dance. ========== And, now for something completely different ... Here's a challenge: Add 10-20 lines to the preclear script that will cause the post-read phase to run just as fast as the pre-read phase for many/most users. For the rest, no change (but there would be such clamoring that they could easily/quickly join the party). [same exact functionality/results as now.] Who's wants to be the hero??? Think about it-- ~5-10 hours saved per cycle for a 2TB drive. [No questions ... just think ] --UhClem

I know you did, and I respect that. (I've been in that position many times, and) That is precisely why I said "take a step back"--meaning to try to get a different view/perspective. But, here's the problem (as I see it): For a marginal drive, that little head-fake () might just cause the subsequent read attempt to be off-track and/or un-settled, BUT, if so, the drive will detect that; also, even if the drive doesn't detect that it hasn't settled sufficiently, and proceeds with the read, it will obviously get ECC failure. In all of those cases, the drive will merely RETRY the read (but this time with no/negligible prior head motion), and succeed. That little dislocation-dance (every 200 "cylinders") is just a (very minor) "waste of time" [looks like only about 0.5% extra], but has no chance of leading to any "feedback". Remember, a drive will RETRY a read 10-20 times before giving up and returning UNC to the driver (and the driver will RETRY 4-5 times before giving up and returning error to the calling program). However, I definitely agree that a new drive should really get a mechanical pummeling!! (But, instead of a couple of gnats, how about a swarm of horseflies.) I give my drives 5+ minutes of constant seeking, which also serves to verify that the drive's seek time is within spec. [seektest -n 20000 /dev/sdX -- my own little hack; don't know if Linux has something like it]. If any relevant component is sub-par, or inclined to be, now's the time to find out. To quote Crocodile Dundee: "Now, that's a torture test." (compared to the little twitches in preclear). I'll repeat this test occasionally (at least a few times per year). Following that initial torture session, I do a thorough surface integrity test (xfrtest ... /dev/sdX -- another personal hack). I try to repeat this once/twice per year, tracking the (very quantitative) results. --UhClem

Joe, I understand what you intend the above dislocation enhancement to accomplish, but I'd suggest that you (take a step back and really) think about it. What it does do is cause a slight (probably undetectable) seek noise, and increase the elapsed time of those phases (apparently noticeably). [Neither of which were your actual intent (but unavoidable side effects of your intent).] --UhClem

Two months older news now, than when I tried telling you ... Have you tried plugging the SansDigital into the MicroServer's eSATA port? [surprise!! ] Probably will, but performance (parity check, etc.) might be yucky. Even there, you will be limited to about 120 MB/s total bandwidth with the PM enclosure. The SiI3132 has a bogus transfer rate limit of ~120 MB/s (even though it is PCIe x1 v1, and should be able to get 180-200 MB/s).

Agreed. But I am a software person, and a seemingly analogous motherboard's BIOS would be an easy starting point for comparison. I had done that too, but only within my limitations (I studied EE [almost 50 years ago] but wasn't good at it). One thing that caught my eye (in the DataSheet) was Table 61 (pg 112) -- Performance mode. But then there is the last entry in Table 28 (on pg 77) for AZ_SDOUT which implies (to me) that Performance mode is always available. Isn't it possible that HP decided to omit/remove a 6Gb/s setting from their BIOS so as to avoid that slight bump in TDP power draw (5.3W vs 4.9W--ref Table 61)? Or, as you surmised, maybe just to cripple the MicroServer market-segment-wise, relative to its more macho Proliant brethren? Hence, that is why I suggested checking another (SB820M-motherboard) BIOS--to see if anything jumps out at you. For example, in the MicroServer BIOS, can you tell me what effect the (SATA) 1.5G setting has, relative to the 3G choice? --UhClem

If it was easy, we wouldn't be having this discussion . There are motherboards that use the same SB820M and DO support 6Gbps SATA. I suspect their BIOS might have some good clues.

Is it possible to enable SATA III/6Gbps? It is documented as being available in the AMD SB820M. Thanks.