ufopinball Posted January 14, 2013 Share Posted January 14, 2013 just downloaded and md5 checked out for me The unRAID Server 5.0-rc10 AiO.zip file that I downloaded an hour ago matches the one I downloaded two days ago, also with a matching MD5 checksum. Quote Link to comment
Enterprise Posted January 14, 2013 Share Posted January 14, 2013 Thanks! just downloaded and md5 checked out for me The unRAID Server 5.0-rc10 AiO.zip file that I downloaded an hour ago matches the one I downloaded two days ago, also with a matching MD5 checksum. Quote Link to comment
RobJ Posted January 14, 2013 Share Posted January 14, 2013 That causes the system to restart and started a parity check, which was ridiculously slow... 10 to 25 MB/s... on rc5 i typically get 90 to 110 MB/s, so i stopped the parity check. I keep an eye on it, if the system gets unresponsive again, or shows extremely slow parity or transfer rates, its going back to rc5... An automatic parity check following a system crash can be exceptionally slow for awhile, all versions, because there may be transactions to be replayed on some or all of the data drives. If you monitor the syslog for the 'disks_mounted' message, then you should see the parity check speed return to normal. By the way, the UnRAID wiki is still reporting 'This site is experiencing technical difficulties'. Quote Link to comment
PeteAron Posted January 14, 2013 Share Posted January 14, 2013 I have the realtec nic: Realtek RTL8111E Gigabit Ethernet LAN, 2x Gigabit LAN ports After running new permissions, my first copy to the array, 5 files totalling abt 20 GB had a sustained transfer rate of over 60 MB/s, which is higher than what I have been accustomed to, about 40 MB/s. Seems okay so far. Edit. I have had to cancel and restart every transfer so far, from win7. Speed is high during the transfers though. Quote Link to comment
limetech Posted January 14, 2013 Author Share Posted January 14, 2013 By the way, the UnRAID wiki is still reporting 'This site is experiencing technical difficulties'. Thanks, I didn't notice that, looking into it now... Also, the download files should not be affected because they are kept with a totally different hosting account. Quote Link to comment
PeterB Posted January 14, 2013 Share Posted January 14, 2013 An automatic parity check following a system crash can be exceptionally slow for awhile, all versions, because there may be transactions to be replayed on some or all of the data drives. Also, if you use cache_dirs, that kills the performance of the parity check while the cache is being populated. Quote Link to comment
ZipsServer Posted January 14, 2013 Share Posted January 14, 2013 An automatic parity check following a system crash can be exceptionally slow for awhile, all versions, because there may be transactions to be replayed on some or all of the data drives. Also, if you use cache_dirs, that kills the performance of the parity check while the cache is being populated. Thanks, for this piece. Usually my parity check is around 120MB/s and it was running at 30MB/s. But this make sense as I just started using cache_dirs Quote Link to comment
Johnm Posted January 14, 2013 Share Posted January 14, 2013 Well RC10 is up and running on my main server (Atlas Virtual unRAID) .. So far is seems stable. Did full parity test and moved 1TB on to the server and a different TB Off the server at the usual speeds. First upgrade I have done since RC5 or RC6. Since I am about to leave town for 3 months.. eep.. I am getting low memory errors while doing a parity check. but that,s not new. (and I think I had found that was due to Cache_dirs) Quote Link to comment
limetech Posted January 14, 2013 Author Share Posted January 14, 2013 Well RC10 is up and running on my main server (Atlas Virtual unRAID) .. So far is seems stable. Did full parity test and moved 1TB on to the server and a different TB Off the server at the usual speeds. First upgrade I have done since RC5 or RC6. Since I am about to leave town for 3 months.. eep.. I am getting low memory errors while doing a parity check. but that,s not new. (and I think I had found that was due to Cache_dirs) What do you mean by "low memory errors"? All cache_dirs does is periodically visit a set of files in order to keep their inodes in memory. If other processes require memory the inodes and any necessary cached data buffers just get claimed and used. Quote Link to comment
Zaxxan Posted January 14, 2013 Share Posted January 14, 2013 I woke up this morning to find that my server had failed to go to sleep. I checked the main GUI and the parity drive was still spinning, I then checked the syslog and the drive should have spun down last night (drive 0). Jan 13 09:40:21 unRAID kernel: mdcmd (2): spindown 0 Jan 13 09:40:21 unRAID kernel: mdcmd (33): spindown 1 Jan 13 09:40:22 unRAID kernel: mdcmd (34): spindown 2 Jan 13 09:40:22 unRAID kernel: mdcmd (35): spindown 3 Jan 13 09:40:22 unRAID kernel: mdcmd (36): spindown 5 I've tried manually spinning the drives up and down and everything appears to be working as normal. I'm note sure if this is a RC10 issue or not but my server has never failed to go to sleep before. . syslog-2013-01-14.txt Quote Link to comment
coco65 Posted January 14, 2013 Share Posted January 14, 2013 I have a 6 drive setup with a SSD cache drive. After writing some data to the user share I made, it went to the cache drive, as it should (I turned caching on for the user share). But the next day the data is still there, it has not been moved. So I set the mover schedule to 1 * * * * * and waited one hour. Nothing happens. This is the entry that turns up in the system log: Jan 14 11:01:01 Tower logger: /bin/sh: initconfig: command not found Jan 14 12:01:01 Tower logger: /bin/sh: initconfig: command not found (when I click the [move now] button in the GUI it works fine) Quote Link to comment
prostuff1 Posted January 14, 2013 Share Posted January 14, 2013 I woke up this morning to find that my server had failed to go to sleep. I checked the main GUI and the parity drive was still spinning, I then checked the syslog and the drive should have spun down last night (drive 0). Jan 13 09:40:21 unRAID kernel: mdcmd (2): spindown 0 Jan 13 09:40:21 unRAID kernel: mdcmd (33): spindown 1 Jan 13 09:40:22 unRAID kernel: mdcmd (34): spindown 2 Jan 13 09:40:22 unRAID kernel: mdcmd (35): spindown 3 Jan 13 09:40:22 unRAID kernel: mdcmd (36): spindown 5 I've tried manually spinning the drives up and down and everything appears to be working as normal. I'm note sure if this is a RC10 issue or not but my server has never failed to go to sleep before. . Sleep is not a function of default unRAID. Whether is works or not from one release to another is not something Tom should be trying to figure out until he is advertising it as a feature. Quote Link to comment
Joe L. Posted January 14, 2013 Share Posted January 14, 2013 I woke up this morning to find that my server had failed to go to sleep. I checked the main GUI and the parity drive was still spinning, I then checked the syslog and the drive should have spun down last night (drive 0). Jan 13 09:40:21 unRAID kernel: mdcmd (2): spindown 0 Jan 13 09:40:21 unRAID kernel: mdcmd (33): spindown 1 Jan 13 09:40:22 unRAID kernel: mdcmd (34): spindown 2 Jan 13 09:40:22 unRAID kernel: mdcmd (35): spindown 3 Jan 13 09:40:22 unRAID kernel: mdcmd (36): spindown 5 I've tried manually spinning the drives up and down and everything appears to be working as normal. I'm note sure if this is a RC10 issue or not but my server has never failed to go to sleep before. . Create a post in the customizations forum for this, but before you do, your syslog shows you have a BIOS firmware issue: Jan 13 09:40:20 unRAID kernel: ACPI: Preparing to enter system sleep state S3 Jan 13 09:40:20 unRAID kernel: PM: Saving platform NVS memory Jan 13 09:40:20 unRAID kernel: Disabling non-boot CPUs ... Jan 13 09:40:20 unRAID kernel: CPU 1 is now offline Jan 13 09:40:20 unRAID kernel: Extended CMOS year: 2000 Jan 13 09:40:20 unRAID kernel: ACPI: Low-level resume complete Jan 13 09:40:20 unRAID kernel: PM: Restoring platform NVS memory Jan 13 09:40:20 unRAID kernel: Extended CMOS year: 2000 Jan 13 09:40:20 unRAID kernel: Enabling non-boot CPUs ... Jan 13 09:40:20 unRAID kernel: Booting Node 0 Processor 1 APIC 0x1 Jan 13 09:40:20 unRAID kernel: Initializing CPU#1 Jan 13 09:40:20 unRAID kernel: [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu Jan 13 09:40:20 unRAID kernel: perf: IBS APIC setup failed on cpu #1 Jan 13 09:40:20 unRAID kernel: CPU1 is up Jan 13 09:40:20 unRAID kernel: ACPI: Waking up from system sleep state S3 Jan 13 09:40:20 unRAID kernel: ohci_hcd 0000:00:12.0: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ohci_hcd 0000:00:12.1: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ehci_hcd 0000:00:12.2: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ohci_hcd 0000:00:13.0: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ohci_hcd 0000:00:13.1: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ehci_hcd 0000:00:13.2: wake-up capability disabled by ACPI Jan 13 09:40:20 unRAID kernel: ohci_hcd 0000:00:14.5: wake-up capability disabled by ACPI As already mentioned, unRAID does not support a "sleep" function, as it is too buggy in various BIOS and hardware. Some wake, some never do, some in incomplete status. If it worked for you in the past, then possibly the newer kernel is making more checks now. Search on google for your specific error might provide more info. Quote Link to comment
Zaxxan Posted January 14, 2013 Share Posted January 14, 2013 I woke up this morning to find that my server had failed to go to sleep. I checked the main GUI and the parity drive was still spinning, I then checked the syslog and the drive should have spun down last nig ht (drive 0). Jan 13 09:40:21 unRAID kernel: mdcmd (2): spindown 0 Jan 13 09:40:21 unRAID kernel: mdcmd (33): spindown 1 Jan 13 09:40:22 unRAID kernel: mdcmd (34): spindown 2 Jan 13 09:40:22 unRAID kernel: mdcmd (35): spindown 3 Jan 13 09:40:22 unRAID kernel: mdcmd (36): spindown 5 I've tried manually spinning the drives up and down and everything appears to be working as normal. I'm note sure if this is a RC10 issue or not but my server has never failed to go to sleep before. . Sleep is not a function of default unRAID. Whether is works or not from one release to another is not something Tom should be trying to figure out until he is advertising it as a feature. Yes I know that. The reason why it didn't go to sleep was because the parity disk did not spin down even though the syslog said that it had. Doesn't unraid control the spin down of the disks? All the disks are set to spin down after 30 minutes of inactivity. Quote Link to comment
Joe L. Posted January 14, 2013 Share Posted January 14, 2013 I woke up this morning to find that my server had failed to go to sleep. I checked the main GUI and the parity drive was still spinning, I then checked the syslog and the drive should have spun down last nig ht (drive 0). Jan 13 09:40:21 unRAID kernel: mdcmd (2): spindown 0 Jan 13 09:40:21 unRAID kernel: mdcmd (33): spindown 1 Jan 13 09:40:22 unRAID kernel: mdcmd (34): spindown 2 Jan 13 09:40:22 unRAID kernel: mdcmd (35): spindown 3 Jan 13 09:40:22 unRAID kernel: mdcmd (36): spindown 5 I've tried manually spinning the drives up and down and everything appears to be working as normal. I'm note sure if this is a RC10 issue or not but my server has never failed to go to sleep before. . Sleep is not a function of default unRAID. Whether is works or not from one release to another is not something Tom should be trying to figure out until he is advertising it as a feature. Yes I know that. The reason why it didn't go to sleep was because the parity disk did not spin down even though the syslog said that it had. Doesn't unraid control the spin down of the disks? All the disks are set to spin down after 30 minutes of inactivity. You can experiment with that yourself. Type /root/mdcmd spindown 0 to spin the parity disk down and then use whatever command is used by your sleep script to determine if it is spinning. If it tests as still spinning after being spun down (assuming it actually spins down) then it might be something lime-tech can address. In the same way, you can use /root/mdcmd spinup 0 to spin the parity disk up. This will let you test you sleep scripts ability to determine it is spinning. Again, create a thread in the customizations forum if needed for further guidance. Joe L. Quote Link to comment
Zaxxan Posted January 14, 2013 Share Posted January 14, 2013 @ Joe L, Ok, I will investigate further. Quote Link to comment
ZipsServer Posted January 14, 2013 Share Posted January 14, 2013 RC10 up and running. Jan 14 13:13:39 Harvard kernel: eth0: Identified chip type is 'RTL8168E-VL/8111E-VL'. (Network) My Realtek nic appears to be working. syslog-2013-01-14.txt Quote Link to comment
Julian0o Posted January 14, 2013 Share Posted January 14, 2013 I cannot start RC10. Updated von RC8a the System stucks at Syslinux startup line. Nothing more. Any ideas? Quote Link to comment
prostuff1 Posted January 14, 2013 Share Posted January 14, 2013 I cannot start RC10. Updated von RC8a the System stucks at Syslinux startup line. Nothing more. Any ideas? read back threw the thread. Tom update syslinux in prep for some other changes. Try redoing the make bootable step of setting up a flash drive. Quote Link to comment
jowi Posted January 14, 2013 Share Posted January 14, 2013 Started a parity check this morning, finished after 12 hours with avg of 96MB/s. V5.0-rc5 did a faster job with avg. 110MB/s... but i guess it's ok. I do have the feeling copying to and from the array is a lot slower. Quote Link to comment
kegler Posted January 14, 2013 Share Posted January 14, 2013 I cannot access the release notes for 5.0-rc10 on the first post of this thread. unRAID has a problem Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Can't contact the database server: Unknown error (localhost)) Quote Link to comment
Frank1940 Posted January 14, 2013 Share Posted January 14, 2013 I cannot access the release notes for 5.0-rc10 on the first post of this thread. unRAID has a problem Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Can't contact the database server: Unknown error (localhost)) Download the zip file with the software. The release notes are in the file 'readme.txt" Quote Link to comment
kegler Posted January 15, 2013 Share Posted January 15, 2013 I saw "Change Log" at the top and didn't read the third line. Upgraded from rc8a to rc10 - New Permissions run - Running a parity check now - Everything is looking good so far. Thanks Quote Link to comment
MaxNL Posted January 15, 2013 Share Posted January 15, 2013 Updated, everything went fine. Unfortunately now I have a very slow writing speed. Copying a file from network (1gbit) to \\server\disk2\dir has a speed of about 2,3 MB/sec (megabyte/sec). How I can download a previous version? (5.0 RC) to check the speed in the previous version (I need 5.0 as I have only 4TB HD). UPDATE: I did few more tests. 1) Network copy > I confirm what I said before - speed around 2,3 MB/s writing to "disk..." share 2) Network copy > Copyng to cache drive get about 7,5 MB/s 3) dd command on "disk..." (/mnt/disk2) get 2,4 MB/s 4) dd command on cache (/mnt/cache) get 2,4 MB/s So it does look there is something wrong (attached my syslog) By the way parity check runs good at about 160 MB/s Any suggestion would be really appreciated. Cheers Max syslog.txt Quote Link to comment
RobJ Posted January 15, 2013 Share Posted January 15, 2013 Unfortunately now I have a very slow writing speed. Copying a file from network (1gbit) to \\server\disk2\dir has a speed of about 2,3 MB/sec (megabyte/sec). So it does look there is something wrong (attached my syslog) By the way parity check runs good at about 160 MB/s I don't see anything wrong. Many network chipset modules will helpfully report the connection speed, but yours does not, so I think your first step is to confirm that you really are connecting at gigabit speeds (you do have a gigabit NIC). See Console Commands for Networking, well rats the wiki is still down... At the console (or after opening a Telnet/PuTTY session), type : ethtool eth0 This should provide the connection speed on a line that begins with "Speed:". Should be 1000Mb. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.