david81

Well, it turns out it was that 1 TB drive that was slowing things down. It's moved on beyond that point and is now cooking along at 130MB/s. I guess it's a good thing I'd planned out retiring that drive as part of the drive shuffle...

Thanks Frank. After letting it run for about 2 1/2 hours it has picked up speed (about 77MB/s now). Not sure if that's the best I can expect from this hardware, but it's certainly better than before. New diagnostics attached in case it helps. CPU is averaging 15-20% and memory is hovering around 37%. vault-diagnostics-20190323-1921.zip

Hello all, I'm hoping someone out there may be able to point me in the right direction to improve parity sync speed on a new/old system. My setup has been running pretty much without issue for 10+ years until I recently started seeing random lockups. I was finally able to catch some errors on an attached monitor that seemed to indicate some problems with the CPU. Thankfully, I happened to have a bunch of old parts laying around and I was able to swap out for a slightly newer (albeit still old by today's standards) MB/CPU combo (MSI H61M-P31 (G3) + Intel Celeron G1610). To add to the fun, I was in the process up replacing my parity drive, in anticipation of adding larger drives to the array in the near future. I had successfully completed a preclear on the old hardware with decent speeds (130MB/s or so). The new MB had a few fewer SATA ports, so I picked up, from ebay of course, an LSI 9211-8i P20 flashed to IT mode. So, all told, I'm working with a new CPU/MB, added SAS card and new parity drive to sync up. Unfortunately, my speeds seem pretty low (max so far has been about 41MB/s. I've made a few BIOS tweaks based on other, similar, threads that I've found, but I'm not seeing much change. Full diagnostics attached if anyone is willing to assist. Thanks in advance. vault-diagnostics-20190323-1656.zip

I know this is dredging up a very old topic, but a quick search of the forum didn't turn up anything promising. Has there been any more thought to changing the free space calc or making it user configurable?

That sounds perfectly reasonable to me. Even better if there were an option to override it in the case where your data drives filled up and you'd still like to transfer to the share while waiting on a new drive to arrive or clear.

So....is there something we need to do to get an official bug report filed on this one?

Here's a screen shot of what I'm seeing on 5.0.5. The Movies share does not have a top level folder on the cache drive currently. The TV share does.

Is this, perhaps related to the use of a cache disk? I just noticed a similar behavior on my setup. User share spans 2 disks, only 90GB free between the two, yet unRAID reports nearly 1TB free. When calculating free space from the Shares tab of the web UI it seems to include cache disk space in the free space calculation for the user share. Is that expected? It only seems to do that if there is currently a top level folder for that particular user share on the cache drive. Personally, I'd prefer to exclude cache drive space from the free space calculation since the cache drive is not "real" space (protected). I can't remember if pre-5 versions behaved the same way, but I only noticed it after my upgrade to 5.

It wasn't even a port 80 thing. I even changed the default port for the web gui to something random as part of my troubleshooting and it still didn't work. Even tried temporarily disabling the Eset firewall and AV protection. It wasn't until I white listed the small DHCP range of my internal network that it allowed access.

I doubt it would be the pop-up password prompt since all the other apps (SAB, Sickbeard, Couchpotato, etc.) running on that box are PW protected and I could access all of them with no issues. I'd love to know if there is some known issue that would cause this.

Safe Mode with Networking = Success Can anyone let me know why? Was it some sort of update that killed my access to the Unraid Web GUI specifically? EDIT: Turns out it was Eset SmartSecurity which I installed a few weeks back. I had to go in and make some pretty explicit allowances. Any ideas why it was just the Unraid interface it had issues with?

Fresh copy of 4.7 and still no go. No spare flash drive laying around currently, but I'll see if I can scrounge one up. At least everything else is working...for now.

Thanks for the try Nate. Still nada though. Do I need to file some sort of official help ticket at this point?

Anyone have any other suggestions of what I may need to try? Should I reload 4.7 and overwrite everything?

Nada on Chrome, Firefox, IE, Dolphin or Opera.

Restarted with a "clean" go script. Still web UI. New syslog attached. syslog1-19-12.txt

I did try killing and starting. Still nada. I'll try removing all add-ons when I get home tonight. It's just weird that there were no glaring errors in the log to tell me anything went wrong.

I've been running a solid unRaid system for quite some time now but had a bit of a hiccup today. I went to access the server web management interface and I couldn't get to it at all. Firefox says "Connection reset". Unmenu works just fine, but if I try to load the main unRaid page, I get an error. I rebooted the server and still nothing. All of my other stuff is running just fine (sabnzbd, sickbeard, mysql, crashplan, etc.) and I can access the samba shares, but no web management. I didn't see anything funny in the syslog, but I'm certainly no expert at reading it. syslog attached. syslog.txt

According to the official CPU support list, it'll handle almost anything, including some of the X6s if I upgrade to the current beta BIOS. With the current non-beta, most of the Propus core X4s are supported.

Well, I finally got around to seeing what this little AMD processor can do, and, well, I think I'll need an upgrade. I had a download needing repair through SABNZBD/par2 and once the repair kicked in, the CPU hit 100% and the download speed tanked. Given that nothing else was going on at the time, this was OK, but I wouldn't mind having a bit more headroom on the CPU. Any recommendations on X2 vs. X3 vs. X4 these days?

I've been reading up on the 5.0 release and it does indeed sound promising. The reason this issue came up today was when I was adding a new drive to the array. The drive had been precleared and all I needed to do was stop the array, assign the new drive to a slot and be done with it. Unfortunately, I couldn't stop the array with the standard "Stop" button due to the other apps running on the cache drive. I eventually got it stopped, but it sure would have been handy if I could have set-up some custom stop functionality. I'm a bit of a linux newbie, but I'll see what I can dig up as far as writing my own custom stop script. Could be fun

Somewhat newbie question here. Is there a way to customize the shutdown/stop array process? e.g. - I'm running SABNZBD, CouchPotato, SickBeard and Crashplan from a hidden folder on the cache drive. I've also got MySQL running with the data stored in this same hidden folder. I'd like some way to have the "stop array" button shut down those apps in a nice manner. Sure I can log in to each one and shut them down individually, but it sure would be nice to build it in to the standard stop/shutdown flow. Any hope on this one?

Just a quick update and thanks to Joe. HPA is no longer present and the "infected" drive has been rebuilt. Even threw in the "spare" 1 TB drive and all is humming along now.

Sounds good. So all I have to do is run "hdparm -N p1953525168 /dev/sdc", reboot and rebuild the "new" disk? I just ran a parity check last night in prep for this, and all is well there.

Alright, so after the BIOS upgrade, I decided it was time to remove the HPA from the offending disk. I read the thread where Joe walked someone through the hdparm command and I think I'm pretty comfortable with that. Before proceeding, I ran the command without setting a size to confirm that I had the right disk and received this: root@Vault:~# hdparm -N /dev/sdc /dev/sdc: max sectors = 1953523055/7368112(1953525168?), HPA setting seems invalid (buggy kernel device driver?) As expected the numbers match what I see in the syslog. I ran it on another couple disks to see what a "good" disk looks like and got a couple interesting results: root@Vault:~# hdparm -N /dev/sde /dev/sde: max sectors = 3907029168/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Vault:~# hdparm -N /dev/sdd /dev/sdd: max sectors = 1953525168/7368112(1953525168?), HPA setting seems invalid (buggy kernel device driver?) sde is a recertified WD20EARS that I just received through an RMA with WD that appears to be working OK, but I'm not sure what to make of that output. sdd is a WD10EADS that has been running great for some time. Do I have anything to worry about here? Any disk I run the hdparm -N command on, I get the HPA invalid message.