July 2, 201313 yr All of the disks are read to determine the missing value before a write can occur. Hmmm I guess I need to learn more about the parity that unRAID uses. I would have thougt (at the most basic level, ang thinking about 1s or 0s even/odd parity) that it would simply involve a "fake" write to the failed disk, and a write to the parity disk that would simply invert whatever is at that location... The old data value, the value of parity, and the new data value are required to compute the new parity value.
July 2, 201313 yr Author All of the disks are read to determine the missing value before a write can occur. Hmmm I guess I need to learn more about the parity that unRAID uses. I would have thougt (at the most basic level, ang thinking about 1s or 0s even/odd parity) that it would simply involve a "fake" write to the failed disk, and a write to the parity disk that would simply invert whatever is at that location... The old data value, the value of parity, and the new data value are required to compute the new parity value. Hmmm i guess you're right, even is there's no "file" where you're writing, there still is *something*, and to determine that, you gotta read everything, so I suppose I should see the improvement later (or better said the return to normal Even though i'd rather not risk anything until the array is fully restored, i assume you could test this specifically by mapping one of the other disks and writing while the other disk was still disabled to compare
July 2, 201313 yr I'd tend to agree with "not risking anything" ... but if you did try it, you'd find this: (a) reading or writing to any disk# EXCEPT the bad one should be at normal speed. (b) reading or writing to the failed disk will be much slower than normal, due to all the extra disk accesses. © reading or writing to a share could be either, depending on whether or not the system needs to access the failed disk to get the share's directory or the specific content that you're accessing.
July 3, 201313 yr Author Wheeew.. Ok... So finally last night the rebuild finished as wellso all is good, all disks green One last question, even though it rebuilt everything with the other disks and the parity disk, was it still recommended to do a final parity check now?
July 3, 201313 yr Wheeew.. Ok... So finally last night the rebuild finished as wellso all is good, all disks green One last question, even though it rebuilt everything with the other disks and the parity disk, was it still recommended to do a final parity check now? Yes. That will check that what was rebuilt was done so correctly.
July 3, 201313 yr Author Ok, so just got back... I left the parity check running after the rebuild and found not many but it did give a few errors Check will start a Parity-Check. (Last checked on 7/3/2013 5:57:47 PM, finding 5 errors.) All disks green and says parity is valid. Now what? Not too many syslog lines since the check started till it ends so posting them directly: Jul 3 13:58:57 Tower kernel: mdcmd (16): check CORRECT (unRAID engine) Jul 3 13:58:57 Tower kernel: md: recovery thread woken up ... (unRAID engine) Jul 3 13:58:57 Tower kernel: md: recovery thread checking parity... (unRAID engine) Jul 3 13:58:57 Tower kernel: md: using 1152k window, over a total of 976762552 blocks. (unRAID engine) Jul 3 13:59:12 Tower kernel: md: parity incorrect: 8632 (Errors) Jul 3 13:59:12 Tower kernel: md: parity incorrect: 8640 (Errors) Jul 3 13:59:12 Tower kernel: md: parity incorrect: 8656 (Errors) Jul 3 13:59:12 Tower kernel: md: parity incorrect: 8664 (Errors) Jul 3 13:59:12 Tower kernel: md: parity incorrect: 29120 (Errors) Jul 3 14:00:16 Tower unmenu[1420]: bad method - 41 1708 2561 7590 0 0 0 0 0 7560 759041-^M Jul 3 17:57:47 Tower kernel: md: sync done. time=14329sec rate=68166K/sec (unRAID engine) Jul 3 17:57:47 Tower kernel: md: recovery thread sync completion status: 0 (unRAID engine) Jul 3 18:12:51 Tower kernel: mdcmd (17): spindown 0 (Routine) Jul 3 18:12:52 Tower kernel: mdcmd (18): spindown 1 (Routine) Jul 3 18:12:52 Tower kernel: mdcmd (19): spindown 2 (Routine) Jul 3 18:12:53 Tower kernel: mdcmd (20): spindown 3 (Routine) Jul 3 18:12:53 Tower kernel: mdcmd (21): spindown 4 (Routine) Should I worry, or was it just those few parity errors and they were corrected?
July 4, 201313 yr Should I worry, or was it just those few parity errors and they were corrected? Five errors after the issue's you've been having is nothing I'd be concerned about. Run another parity check to confirm you get zero this time, and I'm sure you're fine.
July 4, 201313 yr Author Should I worry, or was it just those few parity errors and they were corrected? Five errors after the issue's you've been having is nothing I'd be concerned about. Run another parity check to confirm you get zero this time, and I'm sure you're fine. After posting (and seeing you were all offline ) I searched and found a couple of threads with similar issues, so I did go ahead and start another parity check. It just finished 2 minutes ago and like you said, it finished with 0 errors now, so all's good What I'm going to do now is stop it, shut it down, and turn it back on again tomorrow, after I have purchased the replacement battery for the UPS Does that sound good?
July 4, 201313 yr Yes, that's a good plan. The UPS will ensure no "dirty" shutdowns ... you'd be surprised how much more reliable your system can be with that !!
July 6, 201313 yr Author Yes, that's a good plan. The UPS will ensure no "dirty" shutdowns ... you'd be surprised how much more reliable your system can be with that !! Ok, so finally got the replacement battery yesterday, so all's back to normal! Right now I hooked up the failed drive to another computer (did so through a SATA to USB adapter, doesn-t seem to make a difference) and will be running a test with the data lifeguard tool you recommended to see what happens... Even though I'd be susprised, what happens if the testing doesn't throw any errors...? On a separate note, I did some more copying now that it's all restored and I'm still getting slow transfer speeds Seems to start out in a "burst" of about 20MB/s and drops to between 10/15 MB/s... Tried hooking up the computer with the source files and the unRAID server to my Wi-Fi router directly, since it also has Gb ports, but nothing, same results... Both computers show to be in Gb connected mode, so now what? Any other tests I can make to find the culprit of the slow transfer? (I did check the transfer speed of the source disk from windows, but while one external disk had a slow 22MB/s speed, the internal disks had about 65 and 95 MB/s speed, so that shouldn-t be a problem).
July 6, 201313 yr Even though I'd be susprised, what happens if the testing doesn't throw any errors...? If the disk tests okay with Data Lifeguard, then I'd use it as a backup drive. You could, of course, try adding it back to your UnRAID server, but once a drive has had issues in that environment, I'd be skittish about using it there. But we all need to have (or at least SHOULD have) backups of our data ... so it'd be a good backup drive. I keep a complete backup of my UnRAID servers' contents on a set of 2-4TB drives that I store in WiebeTech DriveBoxes [ http://www.amazon.com/WiebeTech-DriveBox-Anti-Static-Hard-Disk/dp/B004UALLPE/ref=sr_1_1?s=electronics&ie=UTF8&qid=1373142644&sr=1-1&keywords=DriveBox ] ... although most of those drives were purchased strictly for that purpose, I also have a couple that have had some issues otherwise, but pass the manufacturer's testing. They work fine as backups, since they're rarely powered on or accessed.
July 6, 201313 yr ... I'm still getting slow transfer speeds Seems to start out in a "burst" of about 20MB/s and drops to between 10/15 MB/s... Double-check all of your Ethernet cables ... unplug them, then re-plug them, being sure there is no "stress" on the connectors. If possible try a different set of cables. Don't forget to include ALL cables in this ... I found a problem for a friend last year that had slightly moved his system to blow out the dust, and had, in the process, stressed the connector on an 18" Ethernet cable between the PC and UPS. Replaced that and all was well. Also, WHAT are you copying? i.e. are you copying a few large (100MB and larger) files ... or a LOT of smaller files. Small files will be much slower, as the directory is updated after each file is closed. What are the specifications of the system you are copying FROM ? [make/model ... and in particular what does Device Manager show as the details for the NIC]
July 6, 201313 yr Author Even though I'd be susprised, what happens if the testing doesn't throw any errors...? If the disk tests okay with Data Lifeguard, then I'd use it as a backup drive. You could, of course, try adding it back to your UnRAID server, but once a drive has had issues in that environment, I'd be skittish about using it there. But we all need to have (or at least SHOULD have) backups of our data ... so it'd be a good backup drive. I keep a complete backup of my UnRAID servers' contents on a set of 2-4TB drives that I store in WiebeTech DriveBoxes [ http://www.amazon.com/WiebeTech-DriveBox-Anti-Static-Hard-Disk/dp/B004UALLPE/ref=sr_1_1?s=electronics&ie=UTF8&qid=1373142644&sr=1-1&keywords=DriveBox ] ... although most of those drives were purchased strictly for that purpose, I also have a couple that have had some issues otherwise, but pass the manufacturer's testing. They work fine as backups, since they're rarely powered on or accessed. Well, there goes that idea! Short test for the drive passed, but then the extended one failed after not too long stating "08-Too many bad sectors found". Additionally after that the drive was not listed under windows anymore even. I guess it's the trash can?
July 6, 201313 yr Author ... I'm still getting slow transfer speeds Seems to start out in a "burst" of about 20MB/s and drops to between 10/15 MB/s... Double-check all of your Ethernet cables ... unplug them, then re-plug them, being sure there is no "stress" on the connectors. If possible try a different set of cables. Don't forget to include ALL cables in this ... I found a problem for a friend last year that had slightly moved his system to blow out the dust, and had, in the process, stressed the connector on an 18" Ethernet cable between the PC and UPS. Replaced that and all was well. Also, WHAT are you copying? i.e. are you copying a few large (100MB and larger) files ... or a LOT of smaller files. Small files will be much slower, as the directory is updated after each file is closed. What are the specifications of the system you are copying FROM ? [make/model ... and in particular what does Device Manager show as the details for the NIC] His cable was from the PC to the UPS? In this particular tests I was copying some tv shows, so several files (between 20-30 per test) of about 300MB each. The source system is a Windows 7 built system, 2GB RAM, 2Ghz proc. and the card is an onboard NVIDIA nForce Networking Controller (which y the way is the same system I've always used before).
July 6, 201312 yr His cable was from the PC to the UPS? Sure. I have mine all set up the same way. A good UPS should have surge protection for your Ethernet connections (all of my units -- APC and CyberPower -- have that). You plug your Ethernet connection into the UPS, then run a short cable from the UPS to the PC. Here's an example (it's the rear of one of my CyberPower units ... note the "In" and "Out" for Ethernet cables:
July 6, 201312 yr In this particular tests I was copying some tv shows, so several files (between 20-30 per test) of about 300MB each. The source system is a Windows 7 built system, 2GB RAM, 2Ghz proc. and the card is an onboard NVIDIA nForce Networking Controller (which y the way is the same system I've always used before). Speed issues can be very difficult to diagnose. If it's not the cables or the ports (I presume you've tried different ports on each of the involved routers/switches), then the next thing I'd try is increasing the RAM on your Windows 7 system. 2GB is (by today's standards) pretty small. I'd probably double that and see if it helps (it certainly won't hurt .. and will be a nice upgrade to the system).
July 7, 201312 yr Author His cable was from the PC to the UPS? Sure. I have mine all set up the same way. A good UPS should have surge protection for your Ethernet connections (all of my units -- APC and CyberPower -- have that). You plug your Ethernet connection into the UPS, then run a short cable from the UPS to the PC. Here's an example (it's the rear of one of my CyberPower units ... note the "In" and "Out" for Ethernet cables: Mine has RJ jacks but RJ-11 for the phone/modem, not RJ-45 for ethernet. Didn't even know they came with those...
July 7, 201312 yr Author In this particular tests I was copying some tv shows, so several files (between 20-30 per test) of about 300MB each. The source system is a Windows 7 built system, 2GB RAM, 2Ghz proc. and the card is an onboard NVIDIA nForce Networking Controller (which y the way is the same system I've always used before). Speed issues can be very difficult to diagnose. If it's not the cables or the ports (I presume you've tried different ports on each of the involved routers/switches), then the next thing I'd try is increasing the RAM on your Windows 7 system. 2GB is (by today's standards) pretty small. I'd probably double that and see if it helps (it certainly won't hurt .. and will be a nice upgrade to the system). I did try the ports, will try switching cables too. Aso have another comuter from which to test, with a Phenom II X4, 3Ghz and 4 GB RAM. Regarding the disk, is there anything worth testing/trying, or if the extended datalifeguard tools test failed on me it's an indication it shouldmjust go in the trash and not waste more time on it?
July 8, 201312 yr Regarding the disk, is there anything worth testing/trying, or if the extended datalifeguard tools test failed on me it's an indication it shouldmjust go in the trash and not waste more time on it? I'd trash it UNLESS it's still under warranty ... you can confirm that by checking at Western Digital's warranty check site [ http://support.wdc.com/warranty/index_end.asp?lang=en ] ... I doubt that it is, but won't hurt to check. If you really wanted to use it for misc storage on another PC (or as a backup) you could use a utility like Spinrite or HDTune to identify WHERE the bad sectors were, and then map them out into a separate partition ... but as inexpensive as drives are these days, I'd just toss it.
July 28, 201312 yr Author In this particular tests I was copying some tv shows, so several files (between 20-30 per test) of about 300MB each. The source system is a Windows 7 built system, 2GB RAM, 2Ghz proc. and the card is an onboard NVIDIA nForce Networking Controller (which y the way is the same system I've always used before). Speed issues can be very difficult to diagnose. If it's not the cables or the ports (I presume you've tried different ports on each of the involved routers/switches), then the next thing I'd try is increasing the RAM on your Windows 7 system. 2GB is (by today's standards) pretty small. I'd probably double that and see if it helps (it certainly won't hurt .. and will be a nice upgrade to the system). Sorry for the delay, had some personal issues.... So I tried another "beefier" computer, and nothing still the same issue, of writing at only about 10MB/s. *BUT*.... reading was another story... Copy files *from* my unraid server to a local drive gave me speeds of about 70MB/s... So given the speed of the drives themselves, I´d say that's about right and maxing out that speed there, so very happy about it. So, what can cause the slow writes and what tweaks or settings can I check to improve it?
July 28, 201312 yr Be sure you've eliminated EVERY cable, switch, and router as a possible cause => i.e. use a different cable between your switch/router and the UnRAID box; take any switch out of the path temporarily (run a cable directly from the router to UnRAID ... or even directly from a PC to UnRAID (they'll both need to be set with static IPs for this test) ... etc. SOMETHING in the path is causing the slow writes -- the most likely candidate is either a cable with a broken pair; or a switch with a defective port. Isolating this can take a bit of time and patience.
July 28, 201312 yr Author Be sure you've eliminated EVERY cable, switch, and router as a possible cause => i.e. use a different cable between your switch/router and the UnRAID box; take any switch out of the path temporarily (run a cable directly from the router to UnRAID ... or even directly from a PC to UnRAID (they'll both need to be set with static IPs for this test) ... etc. SOMETHING in the path is causing the slow writes -- the most likely candidate is either a cable with a broken pair; or a switch with a defective port. Isolating this can take a bit of time and patience. Well while I haven't started troubleshooting it yet, I do know about that (I'm a network engineer and that's what I work as ), all PCs involved have static IPs, and there is a single switch between them. Given it's the same from the two PCs I tested from, if it was a network problem I can dicatd the two ports that the PCs are connected to (as a write to them works fine), and the switch in general for the same reason. I could try first connecting the server to one of those ports and test, to either eliminate or blame it's port, and if that's the same try a different cable for the server and see... (It wkuld be very weird for the transmit pair on the PCs to be bad at the same time, but as writes to the pc are fine, swapping ports between the pc and server would also do the job for a test to eliminate faulty pc trasmit pair/server receive pair). If these dkn't shed light, I would have to dog deeper into the server itself I guess?
Archived
This topic is now archived and is closed to further replies.