• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About UhClem

  • Rank
    Advanced Member
  • Birthday


  • Gender
  • Location
    NH, US
  1. Good! The drive on sde, and the port itself, are fine. (Maybe just a little slow at the very very beginning. Or maybe not even that. It could be that that drive is a little slow in going from the "active/idle" state to the "active/active" state. Not to worry. But, if I (or you) were curious, reversing the numbers in the "for ..." line would tell the story. Thanks--now, there is a permanent place for this information. (We will leave the ID of the 5th port location for the next guy.) Yes, the actual downloaded file (dskt.txt) was moved, and renamed, when: >>> change that to mv /boot/dskt.txt /dskt I think you should keep "dskt" (it is tiny), but the question is "Where?" Guys, help me & Zippi out here ... [Again, I don't use unRAID]; what is the (non-volatile) equivalent of /usr/bin (or, maybe better [if it is in $PATH], $HOME/bin)? --UhClem
  2. There might be a problem with the sde drive (or even the port it's connected to). Run the following: for i in 0 1 3 5 10 20 do /dskt O $i e [that is a capital-O] done and please report the results.
  3. No we were just pushing it to its limits, so you could know how best to use it. You can definitely ignore those warnings. (They were [harmless] mistakes by unRAIDs logger.) No clear reason to change the card. You can even use the other 2 ports for other (than unRAID) drives--like a DVD/BluRay drive, or a backup drive thru an eSata adapter on the case rear. Or, if you really expand your unRAID array (beyond 9 drives total), you can put an additional unRAID data drives on those 2 ports. It just means that Parity Checks, and Array Rebuilds, will run ~15-25% slower. One last question (but no more tests) which 4 physical Sata ports were we just using? The four closest to the rear of the case, or the front of the case? thanks --UhClem "If you push something hard enough, it will fall over." Fud's First Law
  4. I agree, but (most probably) not pertinent to the goals of the testing.
  5. Thanks. The first set are the speeds for the drives, tested individually. That is, with no contention (with other drives) for the controller (and its x2 [pcie v2] limit of ~750 MiB/s, or, and most important in this case, no contention for the single Sata port (which all 4 are multiplied off of) (and its 6Gbps [~550 MiB/s] limit). Those numbers serve as reference points for further testing ... The second set are the speeds for the drives, tested concurrently; all competing for the resource(s). In this example, the total bandwidth provided (by the 9705 port multiplier) was only ~480 MiB/s [vs 550], hence exposing it as the constraining component. That may turn out to be typical overhead for Port Multipliers, in general. (When I subject a SiI3726 port multiplier [10+ years older; only Sata II] to a similar test, it provides a maximum of ~240 MiB/s. There is some specific significance of all of this, for you Zippi. You should probably only put 2 of your unRAID array data drives on the multiplied ports, along with the SSD. The other 3 (native) ports can each have an array data drive. Your parity drive(s) should go on mobo ports, as can additional data drives. What do you think, johnnie.black? (You've played in this sandbox, right?) --UhClem
  6. Thanks, jonathanm. (I'm not an unRAID user.)
  7. Proceed with the download, install, and testing of dskt. Thank you.
  8. Yes, that will be fine for our testing purposes. The installation & testing commands will instead be: mv /dskt.txt /dskt chmod 755 /dskt /dskt X a b c d (that is a capital-X followed by the 4 letters [on paper] [e.g. sda => a, etc.] /dskt a b c d (similarly) [After we're all finished with testing, you should move /dskt elsewhere; it's not good to clutter root.] This is a quick and painless procedure (like the dentist says ...) --UhClem
  9. Zippi, one more test please: ./dskt b c d (Only the 3 Reds; omit the SSD.) Thanks. --UhClem
  10. Everything's cool. Here's the deal: The first line (ending in SControl 300) is the solid connection (ie, link up 6.0 Gbps) from the multiplied (remember my earlier post?) Sata port on the 9235 to the single upstream port on the 9705. The 2nd line is the 9705 actually identifying itself. The 3rd line is the 9705 initializing its first (of 5, downstream) Sata ports; perfectly normal. The 4th line is the 9705 reporting that that link is down (because nothing is connected to it. The 5th line is the 9705 initializing its second Sata port. 5th line is the 9705 reporting that it has a solid (and full speed [6Gbps]) connection to a Sata drive on that 2nd (of 5) Sata port. The next pair of lines are the same explanation as lines 3 & 4 (except relating to the 9705's 3rd port). And same for the next two pair in your post for the 4th & 5th empty ports. Then, in your post the typical successful report for the device (SSD) itself. Now, I want you to do something for me. OK? Just to be safe, shutdown the system. Connect at least two, and preferably three, of your WD Red's to the new card. Do it this way please: Connect one Red to the port that is a "partner" of the SSD's port, and the other two Reds to the partnered pair of ports adjoining that first pair. Now, reboot. Verify that all looks cool in this new syslog (based on the concepts in my above explanation). If not, post the snippet from the new syslog. But if all is OK, make note of the 4 device names assigned to the SSD and the 3 Reds (on a piece of paper). Download the attached (below) script (dskt.txt) to your current directory. Then: mv dskt.txt dskt chmod 755 dskt ./dskt X a b c d (that is a capital-X followed by the 4 letters [on paper] [e.g. sda => a, etc.] ./dskt a b c d (similarly) Please reply with the two 4-line outputs ... and we will all learn something. Thank you. --UhClem PS Note that the script only reads from the disks; worry not. dskt.txt
  11. You put it in your signature. But I bet that you thought signatures stopped working since you weren't seeing them. You have to enable the viewing of signatures, as a reader. Go: "3 horiz bars" (in upper right of the forum window [not your browser]) -> Account -> Account Settings -> Signature ; then Enable "View Signatures". [ To get the details I wanted, to provide you advice, I looked at the specs for your mobo (model# in your sig). It looked "weird" to me, but what do I know--I did my most recent (and probably last) build in '08. So, figuring everyone else probably knew all about it, I GOOG'd for it, filtering for this forum. And, there was the back-story. ] Since your sig says your 850 EVO is mSATA, is it not using the mobo's "mini-sata"? Or, does other weirdness preclude that? If it can use it, do so; and put the 3TB in that (now-free) Sata port. The goal is to offload the bandwidth "stress" from the MV8. I'm betting that the QM87 chipset (on the mobo; supplying the satas, etc.) can handle at least 700 MB/s. --UhClem "Are we having fun yet?"
  12. Almost certainly, you should put your 3 x 6TB drives and the 3TB on the 4 Sata ports on the motherboard. By the way, that is one strange motherboard -- but, as they say, "Don't look a gift horse in the mouth." Right, shooga? ["Strange", as in PCIe v1 and USB3, and more rs-232 ports than disk ports; but it does have 2 x GbE LANs.] --UhClem
  13. I realize that now you're just trying to save face. Remember, I have read it, more than once. That told me all I needed ... (see RobJ's summary of that paper). Why not just admit that you were flat out wrong when But, when asked to document that assertion, just silence. -- UhClem "I think we're all bozos on this bus."
  14. 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)
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.