mjstumpf

Members
  • Posts

    40
  • Joined

  • Last visited

Everything posted by mjstumpf

  1. 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?
  2. 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 :-)
  3. 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?
  4. 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).
  5. 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..
  6. 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.
  7. 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..
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. $35 gets you a 4 port ICH7. Not sure about Unraid compat. Will find out ;-)
  16. It wouldn't surprise me a bit if these were new drives. Failure rates are at 25% for most manufacturers at the moment. Some people have reported that a beefier, more stable (how the hell do you measure that without an oscilloscope?) power supply stopped constant seagate dropouts.
  17. High amounts of ram does not seem to help with transfer speeds. I think the cache gets flushed very often which tends to interfere with transfer speeds (at least from some of my tests). From what I've been reading the samsung spinpoint F3 drives are amoung some of the highest benchmarked drives for write throughput these days. can't even find the 500 gb drives. I bought a pair of 1tb which use the 500gb platters. Ack. I meant 4TB of drive storage. You know, it's funny. I've read on this forum that the Samsung F3 were among the worst performing. But here's the thing: A high level view of newegg comments seems to indicate that they don't suffer the obscene failure rate afflicting other 2tb drives, so I'm likely buying only them.
  18. Regarding SSD-as-cache: One should be quite careful here--I have friends that deal with mass distribution of these, and they tell me to be quite cautious as the failure rate in most brands is unbelievably high. (I'm asking for more details; Kingston and Samsung were the only exceptions; but some Kingston lines appear to be rebadged Intel, so I wonder if all of kingston is secure) Now, knowing how they work, I would suspect that a teracopy-style-write would fail in such a failure mode, which is what you want. I also wonder if my style of usage (occasional, large file storage, NOT as a high-write, sparse SQL db drive) would also mean I could pick anything and it would last forever. But then there's the cost. $130 for a 60gb (on sale) + $130 for another 60gb + $20 for a 2-port SATA and we're talking about another $300 for _convenience_; I'm not sure that this is worthwhile, if I've driven other components (because it's a new array purchase) toward 40mb/sec sustained write performance. Frankly, for $300, I'd almost rather have another 4gb of storage. I'm more inclined to stick spare 500gb drives in as cache.
  19. Are you sure about that? What are you basing that on? I actually don't believe that's the case (in any significant amount. If you tell me it dings 1 MB/sec in overhead or adds some small level of throughtputvariance, ok). When writing blocks out, there is no dependency between the drives from a driver's perspective. Ability to soft raid-1 the cache data would be ideal, yeah. Kills another sata port, but I'd probably still do it. I was more worried about corner (inflection point) cases inside the mover script: Start, but don't finish transfering a file, mover "moves" incomplete file, file xfer finishes, mover declares victory, deletes complete file. But, having looked at the mover script, I don't think that can happen. I'm going to test it a few times with big files though ;-)
  20. Looking to build an Unraid server where cheap and slow is fine. Let me know if you have a spare.
  21. I remember now, more of my rationale: Because it's another moving part that can break. There's a reason that I use Teracopy to move files - it verifies (by hash) that a file made it to the destination unchanged. If I use a cache drive, I'm taking a risk that the file makes it to the cache drive unchanged, but breaks during the move. You may think that's crazy, but it's not. Move enough files and it will happen to you, and you will be shocked and surprised, and then realize I'm right ;-) Is the mover part a script? If I can enhance it to copy-verify-delete, that would solve it.
  22. Why the refusal to use a cache drive? I consistently see 50 - 60 mb/s write speeds to my older, slower cache drive. My recent tests with SSD drives pushed that up to over 70 mb/s. That's nearly double the fastest speeds other users have reported without a cache drive. Maybe you're right, and this is all somewhat moot. I had been initially avoiding it because it chews up a SATA port, and adds an always-on drive (heat, power, space). My needs put me at about 10 TB, which is 6-8 drives, depending. This is an easy number to deal with; but it's just short of the cusp of inexpensive expandability. I don't need 20 drives, but in 2 years I might need 10. But maybe dealing with an SSD + a cheap 2-port PCI-e adapter actually would be far cheaper (and better) than the alternative. I'll look into it. My preference, anyway, would be to populate with slower, lower power drives and mitigate cooling concerns (during parity checks in particular) signficantly. I know, I know: "Buy a HW raid-5!!!". I actually own one, and want to get rid of it in favor of Unraid, because almost every characteristic of Unraid is a better fit for my needs than HW raid-5.
  23. Gary, it looks like you have some serious competition: Suddenly, I feel like I'm in a bar with some guy saying "Hey, that guy over there says he thinks you're a wuss!".
  24. I saw that you mentioned this before. How did you do this? Manually plucking the driver and pieces and setting it up? What was the purpose--to increase utilization of the NAS box overall (running daemons, etc)?