mjstumpf

Thanks all for this great info. I really appreciate it. However, I'm getting really lost. Supermicro MBD-X8SIL-F-O is regarded as really stable. I get that.. but, Can it take 2 of the AOC-SASLP-MV8 cards at .21 firmware? (I want to be able to use 4tb drive) I saw one mention about losing ability to monitor temperature.. does this happen? Is there a workaround?

Ok, as Joe suspected, I think what was happening was that unclean shutdowns were inducing a NOCORRECT parity check on startup. I see the command now in the log (when I press the "parity check" button in the GUI): May 8 20:30:02 Tower kernel: mdcmd (26): check CORRECT And this check ran with no errors. So, we're good here. Thanks :-)

Actually, funny you mention. The parity check started on its own when I boot the server. But, at least one of them I manually invoked by pressing the big "check parity" button from the web GUI. Keep in mind this is 4.6 -- How do I know if what kind of check I'm running? I don't think I saw that in /var/log/ ... I'm starting to think that in the case of the 2 consecutive, what I saw was "NOCORRECT", followed by an implicit "CORRECT" (from the web gui button). Perhaps a third test now will come back cleanly?

Unraid 4.6; 10 drives (first logical/physical 6 through onboard SATA, then 2 through Sil3132, then 2 through Sil3132). I had no parity drive for a long time. (long story, no lectures please; I understand the value) But, with this config, I had previously used parity drives with parity checks, and it would check cleanly. Now: - I do a parity check, and I come up with 25 or so errors. - I repeat the check, and there are 24 errors, in the same places. - I change memory from 16GB down to a smaller 1GB config that previously also cleanly worked - I do a parity check, and I get 7 errors - Repeat the parity check, same 7 errors in the same locations: root@Tower:/var/log# cat syslog | grep parity May 7 22:28:52 Tower kernel: md: recovery thread checking parity... May 7 22:29:06 Tower kernel: md: parity incorrect: 1457392 May 7 22:30:32 Tower kernel: md: parity incorrect: 11666128 May 7 22:31:07 Tower kernel: md: parity incorrect: 16181704 May 7 22:31:09 Tower kernel: md: parity incorrect: 16373960 May 7 22:34:02 Tower kernel: md: parity incorrect: 38137720 May 8 00:46:17 Tower kernel: md: parity incorrect: 1033482040 May 8 00:53:42 Tower kernel: md: parity incorrect: 1091494984 What should I look for? I'm grinding on the memory with memtest86+ right now, and I'm thinking later I should grind on it with google's stressapptest (perhaps it's the pathways at fault more than the memory itself).

So I'm trying to make this work, as this is a really important feature to me. I'm linux-saavy, but I want to understand how people have done this: I booted with RiP linux, ftp'd over the lm_sensors package that I had pre-built (it builds statically automatically. I love those guys). Did a sensors-detect: Found `Fintek F71889FG Super IO Sensors' Success! (address 0xa00, driver `f71882fg') So I do: dmesg | grep f7188 And the driver isn't there. So how do I most easily / efficiently build it? Is it practical for us to rebuild the kernel or its driver? Not having it is really not a great option, and I've heard of people turning unraid into a full distro with gcc and everything..

HUGE difference going directly to rsync server and cutting samba out. HUGE. 13-15 MB/sec with Samba; 25 MB/sec with "rsync --daemon" (in my simple test). Going to let it run on the big files now and see how it goes.

.

I'm more or less using defaults on large files and incompressible material. I don't think buffering is going to help much unless it defaults to something absurdly low. I haven't noticed the new file allocation "feature" you described, but thanks for the heads-up. I can tolerate 15mb/sec, especially as it's a "once a day" or "once a week" turn-on, sync-up, turn-off sort of thing. But I'd like it to be better if possible..

I'm using rsync to mirror one unraid server to another via smbmounting the disks and rsyncing one disk to another. Neither server has parity enabled. Raw write speed from windows with teracopy is solid at 48mb/sec for both of them. Using rsync, however, I'm getting on avg 15mb/sec. Now maybe I shouldn't complain too much as it's verified; effectively 30mb/sec if I factor that in. But still, is there something I can do to improve this? I did read somewhere that the SMB layer might provide some delay, but I'm suspicious that it introduces this much performance hit. Still, I will try running "rsync --server" and eliminating it. Anything else?

I'm not so sure about this; Newegg, and to a lesser extent Amazon seem to have vibrant, active communities that, I suspect because they're so established, actually prompt people to review--good and bad. That said, you're not wrong. It's a hard-to-know problem. But it's not unknowable. Drive failures tend to occur in batches due to manufacturing defects. That's why it's good advice to buy drives over time. It's actually also good advice to buy older, established drive models that have had the kinks worked out. At this moment, I'm trying to not follow either of these. By reading reviews, it is very clear that _at the very least_ lots of bad WD, and especially seagate LP 2tb drives are being shipped. When you have people buying 8, and 6 of them fail within a month, and this is not an isolated review (UPS kickball match involving that pkg), there is not just a problem--there is a HUGE manufacturing/QA problem. Maybe that problem is the electronics being hypersensitive to power supply (as one Seagate review suspected; they had 4 "bad drives", swapped PS to a newer, beefier, one; problem GONE); maybe the problem is newegg "packaging". Maybe the problem is, that because these drives take so damned long to do surface scans, as of 6 months or so ago WD/Seagate stopped bothering to QA a drive before they left the factory, figuring "Screw the customer, we're in a price war". It would be interesting to see what the SMART data says on delivery. The samsung drives have one review (if memory serves) complaining of failure. Is that because the drive is more expensive and thus doesn't sell as much? Yeah, certainly a possibility. It's still got a large pile of reviews, though. I think it is a reasonable conclusion to say that my odds are better with the drive that doesn't have many, many reviews indicating 75% failure rate in a month on a sample set size of 8. I'll take my chances with Samsung for now. This is all academic, anyway. I may end up with high failure rates from the Samsung, too.

You know, I've ignored a lot of this kind of stuff so far, but you just need to shut the hell up. I included plenty of qualification in my comments: If you think I'm wrong, fine. Go buy whatever you like. Why isn't that good enough for you? Why must you swing your cock around with ridiculous statements like these? You can't be bothered to read, carefully, what I said and why I said it. Oh, and while of course, "I don't count", so far badblocks sweeps have turned up errors in both WD drives, but none in the Samsung. Take that for what it's worth.

My comments were not made as idle speculation. I tried to beat the odds 6 months ago, and I failed rather spectacularly. Newegg shipped me one drive that lasted an hour before click-of-deathing, and the second drive lasted a week. That's 2/2 DOA, straight from the factory. If you read the comments carefully you can see enough reports to realize there are grievous problems. Don't believe me? Call me crazy and try your luck. Failure mode tends to be slowly-worsening performance followed by "endless click of death". Good luck. Newegg actually improved their packaging a bit. As for whether or not samsung drives are indeed higher quality, we'll see. I've ordered a bunch of them. I've never seen such a clean Newegg comments set.

Update on this: got the WD EARS drives and the Samsung Spinpoint. Windows over-the-wire writes go 40mb/sec typical, and iozone posts the spinpoint as slightly faster (36 mb/sec write) than the WD. To me, that makes the Spinpoint an obvious choice; it appears to have a very low failure rate. It's even on sale at newegg right now for $150.

Direct answer: Intel pro/1000. All kinds of server chipsets available from surplus stores; new pci-e version from newegg $30. What you didnt ask for: Just use onboard. Seriously. An extra 5-10 MB/sec transfer rate, if you can even get it (you can't, most likely), is not worth the significant cost and care you must put into quality switches, quality NICs everywhere, and quality cat6e cabling. There is a lot non-obvious. Like, in an nForce board, I stick in an pro/1000 card, and it performs signficantly worse than the onboard non-jumbo-frame ethernet. Score! If you're getting 60-70MB/sec, just declare victory and be happy.

I've read reports that the EARS 64mb cache makes a large difference. Putting a jumper on a drive, when the bag and drive both say to do it (and how to do it) is not rocket science.