January 24, 201214 yr unRAID 4.5.6 static IP been working fine for nearly 2 years without a single issue relating to file transfer using various media players and as a backup points for 2 XP machines, backing up around 30GB at a time Recently got Windows 7 64-bit Home Edition on a PC. When trying to copy 108GB of files and folders to unRAID using Win 7 via a mapped drive, it calculates fine, starts to copy and then at some point (35mins & 55mins) in the copying process it crashes the unRAID server, it becomes unresponsive, I cannot ping it, login via web GUI, ssh or console, it requires a hard reboot to get it up and running, after which it starts a parity check, last time it found 40 errors, after the check had finished it works fine again - I repeated the whole exercise and it did it again. The drive is mapped using the same credentials I was using with my XP machines, for all intent and purpose it is indentical, some of the files/folders have been copied, around 90GB of 108GB in the first attempt, and 23GB out of 108Gb for the second attempt. There isn't much in the unRAID logs as it has to be rebooted.
January 24, 201214 yr unRAID 4.5.6 static IP been working fine for nearly 2 years without a single issue relating to file transfer using various media players and as a backup points for 2 XP machines, backing up around 30GB at a time Recently got Windows 7 64-bit Home Edition on a PC. When trying to copy 108GB of files and folders to unRAID using Win 7 via a mapped drive, it calculates fine, starts to copy and then at some point (35mins & 55mins) in the copying process it crashes the unRAID server, it becomes unresponsive, I cannot ping it, login via web GUI, ssh or console, it requires a hard reboot to get it up and running, after which it starts a parity check, last time it found 40 errors, after the check had finished it works fine again - I repeated the whole exercise and it did it again. The drive is mapped using the same credentials I was using with my XP machines, for all intent and purpose it is indentical, some of the files/folders have been copied, around 90GB of 108GB in the first attempt, and 23GB out of 108Gb for the second attempt. There isn't much in the unRAID logs as it has to be rebooted. telnet into unRAID and run a tail -f -n 50 /var/log/syslog Now copy some files over and see if you can get it to crash during the copy. The only other thing I would do is check to see if there is a driver update for the NIC on your Windows machine.
January 24, 201214 yr This doesn't answer your question as to why it's happening but I've noticed "better" performance with UnRAID v4.7 FINAL and Windows 7 x64 than with previous versions of UnRAID. I don't know if anything changed specifically but the rate at which my transfers time out or fail to initialize has decreased since I upgraded from 4.6 (for another issue relating to files not being closed properly during scans using YAMJ and UnRAID).
January 24, 201214 yr Author Thank you both for the replies. I'll pull the logs and post, I'm pretty sure this issue is repeatable, watching tail might be difficult as the time it takes to copy is significant, several hours IIRC, but I'll see what I can do. I let Win7 install the drivers at clean install, AFAIK it updated the drivers during one of its update cycles (the machine has only been up about a week) but I will check - BTW, it is a wired Gb to Gb link to unRAID. I was holding off going to 4.7 as I have no real need, and reading the release notes for it, I couldn't really see anything related (bug fixes etc) to the issue I'm having, so I held off, that, and it has been working perfectly with XP machines...but if needs must I may have to give it further thought.
January 25, 201214 yr Author Okay, I updated the NIC driver, it was on 7.2.1127.2008 to 7.46.610.2011, a significant jump. It is an onboard device, Realtek PCIe GBE family (8011B I think) After the last crash and reboot, the parity checked out as okay, no errors found. Did the same copy again, with the updated NIC drivers and it failed in the same way. Output of tail: login as: root [email protected]'s password: Linux 2.6.32.9-unRAID. root@rutland:~# tail -f -n 50 /var/log/syslog Jan 24 21:28:34 rutland sshd[6782]: error: Could not get shadow information for root Jan 24 21:28:34 rutland sshd[6782]: Accepted password for root from 192.168.1.8 port 1216 ssh2 Jan 24 21:28:34 rutland sshd[6786]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:28:34 rutland sshd[6786]: lastlog_openseek: /var/log/lastlog is not a file or directory! Jan 24 21:28:34 rutland sshd[6786]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:28:34 rutland sshd[6786]: lastlog_openseek: /var/log/lastlog is not a file or directory! Jan 24 21:29:46 rutland sshd[6799]: error: Could not get shadow information for root Jan 24 21:29:46 rutland sshd[6799]: Accepted password for root from 192.168.1.8 port 1217 ssh2 Jan 24 21:29:46 rutland sshd[6803]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:29:46 rutland sshd[6803]: lastlog_openseek: /var/log/lastlog is not a file or directory! Jan 24 21:29:46 rutland sshd[6803]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:29:46 rutland sshd[6803]: lastlog_openseek: /var/log/lastlog is not a file or directory! Jan 24 21:30:18 rutland sshd[6815]: error: Could not get shadow information for root Jan 24 21:30:18 rutland sshd[6815]: Accepted password for root from 192.168.1.8 port 1218 ssh2 Jan 24 21:30:18 rutland sshd[6819]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:30:18 rutland sshd[6819]: lastlog_openseek: /var/log/lastlog is not a file or directory! Jan 24 21:30:18 rutland sshd[6819]: lastlog_filetype: Couldn't stat /var/log/las tlog: No such file or directory Jan 24 21:30:18 rutland sshd[6819]: lastlog_openseek: /var/log/lastlog is not a file or directory! It locked up after about 5 minutes this time, same copy. Is it worth running reiserfsck? I'll pull the SMART logs later on.
January 26, 201214 yr Author Here is the SMART report for the drive it was writing too at the time. One other thing to note, I'm using a backup application (Cobian) to write this 108GB of data, it is possble that the app is causing the issue, however, this raises a few questions. 1) If it is down to the app, shouldn't unRAID handle this more gracefully than gpoing to a hard crash? 2) The same app was used on XP and worked without issue for 2 years! There is entry in the Windows log at the time of the failure, to do with VSS: 0x80070005, Access is denied. Operation: Gathering Writer Data Context: Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220} Writer Name: System Writer Writer Instance ID: {3ca9e4f4-e1e7-48c4-9f3b-9b4006382786} I will try a direct/regular copy from Windows and see how that does, but it does worry me, keep crashing my unRAID like this, and it puts it out of action for around 600 minutes. === START OF INFORMATION SECTION === Device Model: WDC WD6400AADS-00M2B0 Serial Number: WD-WMAV51001544 Firmware Version: 01.00A01 User Capacity: 640,135,028,736 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Wed Jan 25 19:56:06 2012 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (12360) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 145) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x3037) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 140 110 021 Pre-fail Always - 6000 4 Start_Stop_Count 0x0032 091 091 000 Old_age Always - 9106 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 079 079 000 Old_age Always - 15596 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 92 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 34 193 Load_Cycle_Count 0x0032 184 184 000 Old_age Always - 49389 194 Temperature_Celsius 0x0022 115 101 000 Old_age Always - 32 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
January 26, 201214 yr Author I did and straight copy and seems to have completed without issue, well apart from this message: "Too many files are currently in use. Quit one or more programs, then try again", so the finger of blame is pointing at VSS or Cobian I guess - still, it does raise the issue as to why unRAID doesn't handle the error gracefully.... Possible fix: http://lime-technology.com/forum/index.php?topic=5004.0 If not, I'll look into some other backup solution for my Win 7 machine I guess. Am I correct in thinking that if I upgrade t o4.7 it will fix the issue? As discussed here: http://lime-technology.com/forum/index.php?topic=5004.75
January 26, 201214 yr This new error is very reminiscent of my problem with YAMJ. I upgraded to 4.7 Final because it addresses an issue with how Windows closes (or lack thereof) files. Checkout the release notes of 4.7.
January 26, 201214 yr Author Hmm...looking like I should just make the jump to 4.7 - did this cause and issue for you? Do you unmenu with 4.7? I'm using unmenu with unRAID at the moment.
January 26, 201214 yr Hmm...looking like I should just make the jump to 4.7 - did this cause and issue for you? Do you unmenu with 4.7? I'm using unmenu with unRAID at the moment. unMenu will work with 4.7
January 27, 201214 yr Author What is the correct method of ugrading 4.5.6 to 47? I have unemnu and would like to keep my cconfigs if possible. I can find plenty on upgrading to betas but not to 4.7, other than the instructions (readme) which advises you to reformat your USB flash. Forget it, found it here: http://lime-technology.com/forum/index.php?topic=10483.0
January 28, 201214 yr Author Upgraded to 4.7, and the issue is still there. I've come to the conclusion that Cobian Backup just will not play with unRAID, there are quite a few options still to try out, disabling VSS/VSC is one of them, but I am concerned that unRAID crashes and burns so badly.
January 28, 201214 yr It's not Cobian. The loading is causing the crash. Do you have any add-ons? Run memtest at least overnight.
January 28, 201214 yr Author There are quite a few variables here, moving from XP to Win7 being the big one, but also the fact that the PC that now has Win 7, essentially the same PC that had XP on it, except for this, it now has a 64GB SSD. The error "too many files...." might be the VSS/System Restore running out of space on the SSD when try to backup 108GB, researching I've read such things as: "Errors of the type "GLOBALROOT\Device\HarddiskVolumeShadowCopyx\..... doesn't exist" may be caused by having run out of disk space on an NTFS drive. Even in the case that you want to create a shadow copy of a FAT-formatted drive, Windows needs to find at least one NTFS drive in your system with enough free space on it to hold the full copy. " and "If you have errors when copying 10s of thousands of files, like I ran into, (error "Too many files are currently in use. Quit one or more programs, then try again") then do the following: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache - hit modify and change to 1 You can also change: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size - hit modify and change to 3 and then reboot" The system has worked fine for around 18 months (approx 4 or 5 reboots in that time), I also have 2 other XP machines backing up to using Cobian without issue, however, they backup a lot less data, aroudn 30GB. A straight file copy from Win7 worked fine, I VSS might have a role in this so I will turn it off and try Cobian again and report back.
January 28, 201214 yr Author I run unmenu, with the following enable. Monthly parity check APC cupsd ssmtp That's it. I did run a memtest86 when I first configured the machine, I ran it several times over a period of a week, no errors, haven't run one since then though, never had a single issue with until Win7/Cobian came a long!
April 30, 201214 yr Author I still have the same issue, I tried changing the queue type but it still fails, badly. The problem is, when unRAID crashes it does a parity check, I don't like having to do this (and also hard rebooting - power sw held n for 5 secs) as part of testing for fixes...and tips?
May 1, 201214 yr If a parity check will not complete it is most likely that a failed disk rebuild will also not work. The parity check problem must be fixed or you have no protection.
May 1, 201214 yr Author Sorry, I think I may have confused you, the parity check does complete with no errors after hard rebooting. Went I meant to say, currently, when I try one of the suggested fixes, if it fails it completely locks the server up, cannot telnet/ssh and fails to respond to pings, it is a hard crash, consequently I have to pull the plug on the server and reboot, at which point unRAID does the parity check, I'm just not happy doing this repeatedly as part of my testing/fix regime. I was going to try this: Add ulimit -n 16404' to the top of my "go" script, but what command do I use to find the current value? Is it sysctl fs.file-max? This command outputs the following: 71826 My Ubuntu PC shows the following: 397364 I see tomm ( http://lime-technology.com/forum/index.php?topic=5004.msg94672#msg94672 ) set his to 413644 I have 1GB of RAM installed. So now I'm confused, what value should I use for unRAID4.7 What is the default value for unRAID?
February 18, 201313 yr Author Okay, I've now tried a bunch of registry and DCOM settings on windows 7 and unRAID still crashes after 1.5 hrs into a 55GB copy, any thing else to try before I give up? As it happens, I also had to backup the kids XP 32-bit PC again, using Cobian, this backed-up ~40GB to unRAID (over WiFi as well!) without issue, the next day, same thing on Win7 64-bit, crashes unRAID every time. Here is the link to the Cobian mods I tried: http://www.cobiansoft.se/oldforum/default.aspx?g=posts&m=24228
February 19, 201313 yr I skimmed through the thread but it sounds very similar to the issue I was having. Take a look: http://lime-technology.com/forum/index.php?topic=16547.msg171213#msg171213 Unfortunately the solution is to get another nic. I've been using a 10/100 that I had laying around and never had it crash because of transfers since then. Just ordered a Intel 10/100/1000 PWLA8391GT today so I can finally have 1000 back.
February 20, 201313 yr Author It does sound similar, I might just order a NIC, they are cheap enough and it will be easy to test as I can crash unRAID each and every time doing this. Having said that, I believe the BIOSTAR A760G motherboard has been used successfully for other unRAID system builds, but, I will give it a shot. What NIC did you get? Did you add the new NIC to unRAID or your win7 machine?
February 20, 201313 yr Well the funny thing is I don't think the nic is really 100% to blame. I tried with many computers win 7 x64 on multiple, xp, win 7 32 bit, but the ONLY machine that could cause a crash was my desktop. So it must be a combo of the nic's communicating. Personally it bother me that a nic on another machine can cause a complete crash on unraid but it is what it is. Bought this one today: http://www.ebay.ca/itm/Intel-PWLA8391GT-PRO-1000-GT-Desktop-Adapter-LAN-NIC-/290825752975?pt=US_Internal_Network_Cards&hash=item43b690d18f For the cost (I was holding off because locally I couldn't find a non realtek chipset card for a decent price) you get a intel nic which from what I can tell are trouble free. I got PCI because I rather use my PCI-e for drives. Let me know changing nic's works, would like to know if it solves your problem.
February 20, 201313 yr Author I've just remembered, I've got one those kicking around some place, the first one I got was faulty, the supplier replaced it though (not from China, from US). I'll try it and see, and to be honest, if it fixes it then I'll just shrug and move on!
Archived
This topic is now archived and is closed to further replies.