March 12, 200917 yr Either I suck at finding things on the form and wiki, or the answer is barried in a big post/old post, or doesn't exist yet... if there is a post, please let me know the search string you used to find it. Now the problem: I have been doing some rather large backups/moves to the unRAID box with Parity enabled (I now know that the slowdown is due to parity and expected), but what seems to be happening today is the drives are spinning down (going to sleep) during a backup and hanging the back on my Windows box. Very strange... The easy "fix" I did was increased the timeout to 5 hours... of course that worked, except for the moves i'm doing are taking longer than that, so at the 5hr mark, the drives spun down! I thought the timers would reset on every drive access? How do I check the timers? Thanks! (and again sorry if this is covered elsewhere).
March 12, 200917 yr What was your spindown timer set to? I have never seen an issue like you are reporting. You'd need to give a detailed accounting, supported by screenshots and logs, that cover te period of time in question. By way of background, there are two different ways that drives spin down. 1 - the drives themselves can maintain a timer and spin themselves down after a period of inactivity; 2 - unRAID knows when it reads from or writes to each drive and it can maintain its own timer and put them to sleep. 4.3.3 unsed method 1, 4.42 uses method 2. It has some advantages and some disadvantages. If you have found a bug whereby the drive is being accessed but still going to sleep, you need to document it so that Tom can fix. But regardless of what puts the drive to sleep, the drive wakes itself up when you access the drive. Unless Windows is timing out there shouldn't be an issue with the drive waking up and handling the I/O.
March 12, 200917 yr Author I'm using version 4.4.2, here are is the stats for the Drive that went to sleep "early": /dev/sdb: ATA device, with non-removable media Model Number: ST3320620AS Serial Number: 5QF4CJLP Firmware Revision: 3.AAK Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 625142448 device size with M = 1024*1024: 305245 MBytes device size with M = 1000*1000: 320072 MBytes (320 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 254, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns I've even seen it happen on the Parity Drive: /dev/sdc: ATA device, with non-removable media Model Number: WDC WD10EACS-00D6B0 Serial Number: WD-WCAU40384147 Firmware Revision: 01.01A01 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5 Standards: Supported: 8 7 6 5 Likely used: 8 I assume that when windows (TeraCopy) hangs, it is either waiting for a response that it never gets due to the drive going to sleep, or simply doesn't retry (which is then a bug with the program, not unRAID, but still doesn't answer why the drive went to sleep in the first place). Is there any way to use unRAIDs timer (I would think that is the better solution so that you don't have to worry about firmware bugs/compatibility issues).
March 12, 200917 yr I'm using version 4.4.2, here are is the stats for the Drive that went to sleep "early": /dev/sdb: ATA device, with non-removable media Model Number: ST3320620AS Serial Number: 5QF4CJLP Firmware Revision: 3.AAK Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 625142448 device size with M = 1024*1024: 305245 MBytes device size with M = 1000*1000: 320072 MBytes (320 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 254, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns I've even seen it happen on the Parity Drive: /dev/sdc: ATA device, with non-removable media Model Number: WDC WD10EACS-00D6B0 Serial Number: WD-WCAU40384147 Firmware Revision: 01.01A01 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5 Standards: Supported: 8 7 6 5 Likely used: 8 I assume that when windows (TeraCopy) hangs, it is either waiting for a response that it never gets due to the drive going to sleep, or simply doesn't retry (which is then a bug with the program, not unRAID, but still doesn't answer why the drive went to sleep in the first place). Is there any way to use unRAIDs timer (I would think that is the better solution so that you don't have to worry about firmware bugs/compatibility issues). I'm guessing some error caused your TeraCopy program to stop, then, after a period of time with no activity, unRAID spun down its drives because they were inactive. A copy of the syslog for the time period involved would provide the clues needed. to figure out which came first, the chicken, or the egg. Joe L.
March 12, 200917 yr Author I'm guessing some error caused your TeraCopy program to stop, then, after a period of time with no activity, unRAID spun down its drives because they were inactive. A copy of the syslog for the time period involved would provide the clues needed. to figure out which came first, the chicken, or the egg. Joe L. TeraCopy didn't stop for 5 hours! It was running for 5 hours, when I checked on it sometime after 5 hours it was "paused"... when I looked at the unRAID box, the drive I was copying to was in sleep mode... with nothing in the syslog file! Mar 12 08:31:03 RCNAS emhttp: Spinning up all drives... Mar 12 08:51:40 RCNAS in.telnetd[2395]: connect from 10. Mar 12 08:51:41 RCNAS login[2396]: ROOT LOGIN on `pts/0' from `' Mar 12 08:55:36 RCNAS in.telnetd[2439]: connect from 10 Mar 12 08:55:36 RCNAS login[2440]: ROOT LOGIN on `pts/1' from `' Mar 12 09:34:30 RCNAS kernel: mdcmd (122): clear Mar 12 10:06:14 RCNAS emhttp: shcmd (32): /usr/sbin/hdparm -y /dev/hda >/dev/null Mar 12 10:06:14 RCNAS emhttp: shcmd (33): /usr/sbin/hdparm -y /dev/sdd >/dev/null Mar 12 12:02:15 RCNAS emhttp: shcmd (34): /usr/sbin/hdparm -y /dev/sdb >/dev/null Mar 12 14:06:16 RCNAS emhttp: shcmd (35): /usr/sbin/hdparm -y /dev/sda >/dev/null Mar 12 14:15:17 RCNAS in.telnetd[4016]: connect from Here (in the morning after the first time I noticed the problem) you see where I initiated the "spin up" for all drives just to ensure they were all awake. I restarted my transfer (after setting the timeout to 5hrs), and you then see where I login again at 2 (from 8:30am restart of transfer, the drive was asleep when I checked on it at 2pm) - the times before that it was awake. So for some reason the timer is not being reset.
March 13, 200917 yr There have never been any reports at all, of a problem like this before. I'm not doubting what you believe you have seen, but I do have to first eliminate other possibilities, such as, perhaps the copy was going to a different drive than you think it was. Would you mind making available a copy of your full syslog, and also, would you indicate what the exact path you were copying to?
March 13, 200917 yr Author That is the whole syslog around the time that the server experienced the issue... I will try to recreate the situation this weekend if I have time (and will reduce the timeout to 1hr to "speed it up").
March 13, 200917 yr That is the whole syslog around the time that the server experienced the issue... I will try to recreate the situation this weekend if I have time (and will reduce the timeout to 1hr to "speed it up"). The syslog segment you posted is from 8:30 to 14:15 on Monday the 12th. Your description of the issue is a bit confusing. When did you start the transfer? When did it stop? (You mentioned it running during the night and you noticing it when you looked at it in the morning. We can see you logging in at 8:51. ) The instructions on how to post a full syslog are in the wiki under troubleshooting. If you elect to not post it, its OK, but there is little else we can use to help figure out what is occurring. (Translation... we are not mind-readers, and without more detail, we might not be able to help more other than to put the blame on the TeraCopy program you are using to perform the copy.) Are you using a "cache" drive? Are you copying to a "user-share" or to a "disk" share? Are you copying via an SMB share, or an NFS share, or via FTP? If a user-share, how do you have space-allocation set? What "split level" are you using? (if any is defined) Joe L. PS. Looking at the TeraCopy web-site, a recent bugs they fixed include: Fixed: Hanging on same drive copy on single core CPU systems. and Fixed: Error when copying entire drive. What version are you using of TeraCopy? Since you are the first to report this issue, and you are the first to mention TeraCopy, and according to you, the syslog shows nothing, and there have been known issues in previous versions of TeraCopy, my gut instinct is to tell you to use something other than TeraCopy.
March 13, 200917 yr Author The syslog covers a period of time that I know for sure that the drive went to sleep during a copy... so Ignore what I said prior as it appears to have just caused confusion. So at about 9am I started a very large copy from Windows to /unraid/disk3/, at 2pm I check on the copy and it has stopped (TeraCopy is in the middle of a file, paused... I am using the latest beta (2 beta 4a, so it isn't related to the "entire drive" bug, or at least shouldn't be... the main reason I say this I will describe below). Starting the backup at (will say 9am for easy typing)... it gets through a good chunk of it, so it was running fine for at least a few hours (lets say, or purposes of illustration, that the copy paused/hung 2 hours in). My sleep timer is set to 5hours... 9am + 2hours = 11am. 11am + 5 hours = 4pm. Why then would the drive be asleep at 2pm? Impossible if the timers worked. So this is why I rule out TeraCopy as the culprit. No "cache" drive. Copying straight to disk3, via SMB share Are there any other tests or hdparm commands I can do on the drive to see what the timer is at?? That would help determine if the counter is being reset upon drive access. I will try to test it out again this weekend and post my syslog again covering the time period (assuming it happens again... otherwise I'll post here and call it a "ghost" of some kind). Thanks for your thoughts!
March 13, 200917 yr Post your whole syslog. The information that is logged during the boot process is particularly important in trying to figure out stuff like this. And sometimes there are other hints as well. Posting the whole thing gives people trying to help you a complete picture and will encourage them to help you. Note that your NAME does appear in the syslog. If you use the unmenu syslog downloader, it is automatically removed. If you use another method, you can edit the file manually if you'd like to remain anonymous. Also, just a suggestion, but I'd recommend that you try to follow suggestions rather than engage in debate about why that don't need to. For example, Joe L. suggested trying to copy with something else besides TeraCopy. Seems like a smart thing to try. You seem to give an argument as to why you don't need to do that. No offense, but if this had been a problem you could figure out, you wouldn't have asked for help here. If you're going to ask for help, you have to put some faith in the helper and not dismiss diagnostic tests or information requests just becuase you don't think they are necessary. Now if they tell you to do stupid stuff like reformat all your disks or buy all new hardware, you have the right so say "wait a minute". But that's not what Joe is suggesting. You should just do what he says and report results. Similar for the syslog. Joe asks for a complete syslog and you try to justify sending only a portion. Just do it. Ask questions about "why" later. Joe L. is a great forum member and has many satisfied customers. Help him to help you.
March 13, 200917 yr It just is a lot easier for us to ask for the whole syslog, than ask for specific parts to be extracted, and explaining them, and where to find them etc. Plus, until we see the whole syslog, we don't always know in advance what we are looking for, until we see it. We do need to see the parts of the syslog that include the "Device inventory" table, and below that, an import table of all of the drives (lines with drive info and the import word), and as you have done already, please include the timestamps with each line. Then please post the contents of the file disk.cfg, which is found in the config folder of your flash drive. The small extract you posted above does not seem consistent with your comments, which is why I wanted more information. It shows 2 drives spinning down in only 1 and a half hours, another in 2 and a half hours, and the fourth in 4 and a half hours. The info I am requesting will show exactly which drives are associated with which device ID's, what their assigned 'slots' and usage are, and what the global and individual spin down settings are. What I can say is that I have never ever heard of a drive being spun down while being accessed, and I can't think of any scenarios in which that could happen either. And even if an errant spin down command had been sent to the drive, it would IMMEDIATELY spin right back up for the very next read or write! The transfer would only have a brief pause, while the drive was spun down, then back up. Transfers don't stop for a spun down drive, they spin it up. If the drive was spun down, then it had not been accessed in quite awhile.
March 13, 200917 yr And even if an errant spin down command had been sent to the drive, it would IMMEDIATELY spin right back up for the very next read or write! The transfer would only have a brief pause, while the drive was spun down, then back up. Transfers don't stop for a spun down drive, they spin it up. If the drive was spun down, then it had not been accessed in quite awhile. Exactly... in fact, any read or write would spin up a drive... So... - We know you are using a third-party program to perform your copy. - We know it can pause during its file-copy (I even read a complaint on the "release" notes feedback, that a "prompt" for cancel/overwrite stopped a transfer during the night, and that the complainer said his entire copy stopped while waiting for that input as he slept.. Sound familiar?) - We know that any disk access of any kind spins up a drive on the unRAID server. - We know that even in the middle of reading or writing a drive, if you spin it down manually by issuing the hdparm commands, it will immediately spin up on the next read/write. - We know (according to your excerpt of the syslog) your drives went to sleep through inactivity at staggered times.. (most likely 5 hours after their respective last access) I still say, the transfer program paused, several hours later (based on your unRAID spin-down timeout setting), the drives spun down from inactivity. Try using file-explorer to perform the copy... It might work better, it might not...but we will eliminate TeraCopy from the equation. it could be a windows network driver problem on the machine you are trying to copy from just as easily. Did you check its error log? or event log? Does TeraCopy keep a log? can you enable a debugging mode on it to see more of its incremental status? Joe L.
March 13, 200917 yr Author Again... thank you everyone for the comments/thoughts! bjp999 Also, just a suggestion, but I'd recommend that you try to follow suggestions rather than engage in debate about why that don't need to. For example, Joe L. suggested trying to copy with something else besides TeraCopy. Seems like a smart thing to try. Firstly, I never stated I wouldn't try something else... the reasons I posted about why I am convinced is was not TeraCopy was two fold: 1. For the math that wasn't working out in my head. 2. I really dislike it when I ask for help and people simply say, never seen that, you should just stop using that program/thing/whatever that is different than what the poster is use to. Not a helpful suggestion, as the sugestor doesn't know the history. For example, I have been using TeraCopy for over a year and have never had an issue copying over the network like this before. The only change, I'm now moving to a machine that uses spindown (I have numerous windows XP, Vista, 2008, Fedora, Ubuntu and CentOS machines where TeraCopy has worked great with!). I love this kind of request/response to my question of "what other command/info is needed" rather than... "Just send the syslog [stupid]". It just is a lot easier for us to ask for the whole syslog, than ask for specific parts to be extracted, and explaining them, and where to find them etc. Plus, until we see the whole syslog, we don't always know in advance what we are looking for, until we see it. We do need to see the parts of the syslog that include the "Device inventory" table, and below that, an import table of all of the drives (lines with drive info and the import word), and as you have done already, please include the timestamps with each line. Then please post the contents of the file disk.cfg, which is found in the config folder of your flash drive. I really like this kind of help because it not only explains why the information is needed, but helps teach new people like me as to how to trouble shoot for themselves. So this weekend I will try to run this test again and follow the suggestions of all of you here (including using a different program to perform the copy). Thanks again! You are ALL kind to take the time to post your thoughts and try to provide help!
March 13, 200917 yr Sorry if you found my post insulting in any way. It was not my intent. Please accept my apology. RobJ is definitely kinder and more patient than me of which all can attest. He is also much better at reviewing syslogs and figuring out what's going on inside unRAD. Please take the time to read the troubleshooting wiki, FAQ, and Best of the Forums (see links in our sigs). I think it will answer many questions you perhaps haven't thought to ask yet. Good luck!
March 13, 200917 yr Again... thank you everyone for the comments/thoughts! bjp999 Also, just a suggestion, but I'd recommend that you try to follow suggestions rather than engage in debate about why that don't need to. For example, Joe L. suggested trying to copy with something else besides TeraCopy. Seems like a smart thing to try. Firstly, I never stated I wouldn't try something else... the reasons I posted about why I am convinced is was not TeraCopy was two fold: 1. For the math that wasn't working out in my head. 2. I really dislike it when I ask for help and people simply say, never seen that, you should just stop using that program/thing/whatever that is different than what the poster is use to. Not a helpful suggestion, as the sugestor doesn't know the history. For example, I have been using TeraCopy for over a year and have never had an issue copying over the network like this before. The only change, I'm now moving to a machine that uses spindown (I have numerous windows XP, Vista, 2008, Fedora, Ubuntu and CentOS machines where TeraCopy has worked great with!). I love this kind of request/response to my question of "what other command/info is needed" rather than... "Just send the syslog [stupid]". It just is a lot easier for us to ask for the whole syslog, than ask for specific parts to be extracted, and explaining them, and where to find them etc. Plus, until we see the whole syslog, we don't always know in advance what we are looking for, until we see it. We do need to see the parts of the syslog that include the "Device inventory" table, and below that, an import table of all of the drives (lines with drive info and the import word), and as you have done already, please include the timestamps with each line. Then please post the contents of the file disk.cfg, which is found in the config folder of your flash drive. I really like this kind of help because it not only explains why the information is needed, but helps teach new people like me as to how to trouble shoot for themselves. So this weekend I will try to run this test again and follow the suggestions of all of you here (including using a different program to perform the copy). Thanks again! You are ALL kind to take the time to post your thoughts and try to provide help! We are trying to be helpful, and still get the information needed. Please understand, the people like yourself who request assistance have HUGE range of experience when dealing with computers. (Everywhere from "walks-on-water" to "can't tread water, and is drowning") We have no way to know the experience level, nor how well they know their equipment and network. I'm glad that TeraCopy has worked for over a year. Have you used it (the current version) with the same volume of data in a single transfer previously? From the same PC? Have you used the same LAN cable? Router/switch? Odds are very good some patches have been applied to the PC in the past year... hopefully none broke the networking... You see, nothing can be assumed... other than the transfer of your data stopped after a few hours. Everything you have said indicates the transfer stopped and that TeraCopy is sitting there waiting, but that the unRAID server sees no input and eventually goes to sleep. We just do not yet know what it is that TeraCopy is looking for. Did you make your own network cables? Are they cat5, or cat5e? All it would take is one bad crimp that is intermittent when it gets cooler at night. (I've got a electronics background, and used to have to deal with temperature sensitive components all the time) Is your parity drive a "seagate" drive? (we would not have to ask if we had a full syslog (hint-hint)) but since we do not, and we still want you to get this resolved, I need to ask.) The seagate drives have had a bad series of firmware versions recently where they "go to sleep" for 30 seconds or so. We don't see evidence of this in the syslog, as it is not an error, just a delayed response. Perhaps TeraCopy times out waiting... If you have one or more of the affected seagate drives, have you upgraded their firmware? Are you running "vista"? It has its own series of issues with network I/O. One easy thing you might do is upgrade to the current version of unRAID. It has a newer version of SAMBA (the program that is involved in the networking) and also a newer version of the Linux Kernel (possibly with newer network drivers) Upgrading to the current version of unRAID involves only replacing two files (bzroot and bzimage) and rebooting. You can even rename the existing two files to make it easy to revert to the old version if you desire. You don't need to re-configure, or re-format, or re-compute parity, and all your data stays exactly as it is... It is worth a try if we exhaust other possibilities. We are just trying to eliminate possible causes. In the interim, hang in there, do not get discouraged... everyone who has responded is being constructive... (and I promise I won't tell you to reformat your hard disks, even if it is the nicest thing you might be able to do with a Vista PC ) Joe L.
March 16, 200917 yr Author Well, I've not been able to duplicate this error, so not sure what happened. Although I have had a couple of times where a transfer has hung (not sure of the cause as no errors in either windows or unRaid). I assume its likely a Vista->Samba version issue, however, not sure why because I have never seen this happen when transferring files to my Fedora 7 server (Samba version 3.0.28a-1.fc7) using share security. And before you say, try the latest version of unRAID... I have, and can't use it due to a bug in the "Simple" security setting (still requires login); so is a bit useless for what I need unRAID to do. Thanks again for the help thus far!
Archived
This topic is now archived and is closed to further replies.