TSM

Have you looked in to using a wireless bridge? That should work.

Excellent job with this release. SASLP user, with system that was put together with budget parts almost 8 years ago. Parity check back to "normal" speeds, and completely anecdotally with no empirical data to backup the claim, my system seems to be "peppier" than it has been in a long time. Less hesitation when navigating through directories mayabe? I was going to upgrade my mobo and cpu to fix the performance issues I was seeing, but now I don't really need to. Is it weird that this makes me a bit sad???

Everyone forgot the best of all time. ***Tyler Durden(Brad Pitt) - Fight Club*** "WHOA! WHOA! OK, you are now firing a gun at your imaginary friend NEAR 400 GALLONS OF NITROGLYCERIN!" Other honorable mentions Lt. Aldo Raine(Brad Pitt) - Inglorious Bastards "You probably heard we ain't in the prisoner-takin' business; we in the killin' Nazi business. And cousin, business is a-boomin'." The Bride(Uma Thurman) - Kill Bill Vol. 1 and 2 "This is what you get for fucking around with Yakuzas! Go home to your mother!"

I must have missed that. This makes sense. Sucks, but makes sense. I wonder if anyone has asked Supermicro about this. Perhaps pointed them to this thread. I mean, up until this started, I was happy with my one and only Supermicro purchase and was likely to purchase another supermicro product in the future. Now I'll think twice about it.

It seems that the discussion in this thread has changed from trying to figure out a "software" resolution to the possible Supermicro card problem, towards hardware based solutions. Things like replacing the card with one from another manufacturer, upgrading your processor, and etc... Is this Limetech's position on the issue? If a software based solution is still being sought, I'd prefer to not spend the money on a hardware upgrade right now.

By far the lowest price for a 6TB namebrand new drive I've ever seen. I don't need more space right now, but this might be one of those too good to pass up deals.

I think that this is a hard issue to get ones head around. Because it seems to display itself differently depending on what your hardware configuration is. I'm wondering if just as new features have been added to unraid over the past year or 2, if the cpu power necessary to successfully run it has gone up? For example, I think there are a couple of people who had this issue, whose problems went away by swapping out a single core processor with a dual core one. And if LT came out and said to me that this is what I needed to do in order to resolve the issue, I'd be fine with that. Not ecstatically happy, but fine. Other operating systems up their required system specs with new versions, why not unraid? It also seems that more than parity check speeds need to be tested. CPU utilization during those parity checks needs to be checked as well. My lowly single core celeron doesn't go above 50% utilization doing a parity check with 6.0B14, but with any version above that it get's pegged at 100%. It seems like a couple people have mentioned parity check cpu utilization in the 80% range with a core 2 duo processor. In that scenario everything may seem fine because your processor is not getting maxed, but is it really fine?

Yes please.

I believe if you are seeing 100% CPU usage it’s your only option, it doesn’t have to be an expensive CPU, any dual core close to 2Ghz or above should be enough. The CPU is not limiting I/O operation. I have a Celeron G1840 and it handles it just fine. There is an underlying issue with reads during a parity check. First off guys, I want to say that I'm so happy there is finally a single thread that seems to be gaining traction with discussing this issue. Several threads have mentioned it before, but this one seems to be on a good track. I have an old slow processor. A single core celeron 440 purchased circa 2008. In Unraid 6.0 b14 processor utilization hovers roughly between 45 and 50% during a parity check. Each version of unraid I've tried after 6.0 B14, cpu utilization gets pegged at 100% during the parity check, and it processes at roughly a third of the speed it normally would. A used\refurbished dual core processor that should work in my motherboard could be had for $20 or less, and I was seriously thinking about trying that before seeing this thread. I really need to save up the cash for a complete system upgrade and I would prefer not to mess around with upgrading the processor in my 7.5 year old server if I don't have to. Also, I don't know if it makes a difference or not, but I have a SASLP, not a SAS2LP. My motherboard is an Intel BOXDP35DPM. I have no plugins(anymore) or dockers on my system. Just running base unraid.

I don't think this issue is on Limetech's radar.

Shot in the dark here, cause I haven't created a vm using kvm yet, but I know from my experience with VMWare workstation that for the "no default gateway" trick to work, both computers have to be on the same vlan. So if your connection is Nat'd for example, it will have to be changed to bridged. No idea how to check this or change it in KVM. In VMWare it's easy though.

We are in discussions about this feature, but no news just yet. Know that it is an active topic right now. Great news jonp! This and the ability to have more than 1 parity drive, and I'm GOOD...

What are you trying to accomplish? Just the cool factor of your unraid server playing an integral part of the setup, or are you actually trying to solve a problem? Cause I'll tell you, you could probably put together or buy a computer capable of what you're describing for the cost of a thin client. Hell, even one of the higher end thin clients are capable of doing what you want with applications running locally, if you are willing to do some tinkering with it.

What does everyone think about this card? http://www.sybausa.com/productInfo.php?iid=1620 It's selling on Amazon right now for $199.99, but I've also see it $20 to $30 more on other sites. If you had 16 drives attached to this card, the PCI Express X4 would be a bottleneck with parity checks wouldn't it?

I hear ya. I'm wondering if there are people out there who are using this type of processor and are having no problems? Admittedly I've been contemplating swapping out my motherboard and cpu for a while now. According to Newegg I bought my mild mannered cpu in February of 2008. http://www.newegg.com/Product/Product.aspx?Item=N82E16819116038 But at this point it's the principle of the thing. I want to upgrade my cpu because I want to. Not because I have to. And frankly the reason I haven't upgraded yet is because until the latest updates my 7 year old hardware has been performing more than adequately for my needs.

For my clarity, are you suggesting he use the different cpu because of a compatibility issue with his old cpu, or just simply because it's faster and therefore a cpu bound process should work faster on a faster cpu?

I decided to downgrade to 6.0 b14, and lo and behold parity check speeds are back to normal. And a screenshot of Top is attached. And as one would expect with unraid, the CPU is not a limiting factor in the parity check, even though it's a 7 year old single core celeron. I found out that the kworker process is directly related to things the linux kernel is doing. So I was very hopeful that upgrading to 6.1 rc1 as alluded to in Squid's post would help me, but it did not. I saw no noticeable difference between parity check speeds in 6.0.1 and 6.1rc1. I noted that earlier in this thread several posts referred to the SASLP and SAS2LP. And it seemed to be that most people thought that the SAS2LP might be a problem. I have an SASLP with 7 drives connected to it in my system, with no open ports to experiment with elsewhere in my system.

I don't think that my parity slowness issue is like what you guys have posted so far. I originally posted in this thread http://lime-technology.com/forum/index.php?topic=41719.0 But it was suggested to me that I should start looking at this thread. I haven't heard anyone mention the kworker process yet. The Kworker process seems to be eating my cpu alive when a parity check is running. Screenshot Attached. What does this process do? Anyone have any ideas as to why it would go wild during a parity check? When I stop the check it goes back down to 0%.

Thanks for the suggestion. That was an interesting thread, but I think I may have similar symptoms but a different problem than what the rest of them are having. My CPU seems to be occupied with some process called kworker, which takes up around 62% of cpu while the parity check is running, but drops down to 0 when I stop it.

Hey, Thanks for being willing to look at this. I removed my email address from the syslog. Otherwise files are intact. I also removed screen and utemper from the Extra folder. Rebooted and tried the parity check again. Made no difference. Also of note is that on the dashboard page my cpu shows that it's getting pegged at 100% when a parity check is running, but returns to single digit utilization when I stop it. unraid-diagnostics-20150724-0739.zip

Parity check speeds on my system got notably faster after I installed my first 6.0 beta. On previous versions of unraid it had taken about 22 to 23 hours to complete, and with the 6 betas, of which I've has several versions installed, it has usually taken about 18 hours. A couple of days ago I upgraded from 6.0b14 to 6.0.1. Everything seemed to be running great, and I had no noticeable performance issues of any kind. In fact, user share access seemed peppy. Yesterday morning I initiated my first parity check since the upgrade. And the speed was very slow. Before the update a Parity check would start out at around 50 to 60 MB/s and near the end get to over 90 MB/s, once some of smaller drives had finished being involved. The parity check yesterday went at between 12 and 18 MB/s. My plan was just to let it go and see how long it actually took to complete before posting anything about this. My thought was that if it was a bad drive or a bad cable, assuming none of my larger drives were causing the problem, once it got past the problem drive it would return to normal, and I'd have a good starting point in troubleshooting. This morning the parity check was only 23% complete after 23 hours. When I tried to access the server's user or disk shares it was completely unresponsive. The web page was at tad bit slow, but still usable. Usually during a parity check share access is significantly slower, but still possible. This morning it wasn't possible, every attempt to access either a user or a disk share resulted in an eventual timeout. Although I noted that a user share access attempt that would have involved 2 smaller drives that had spun down already, spun them up. At this point the web page was still open on my workstation, from when I had checked the progress before. I decided to stop the parity check and reboot the server. Parity check stop worked, and then when I went to take the array offline it couldn't unmount the disks. It just scrolled messages about that at the bottom of the webpage screen. I've only seen that happen once before. When I was migrating my disks to XFS, I accidentally left a MC session open in Screen, and to unmount the array I had to exit out of that first. But I assure you that to my knowledge nothing like that was going on this time. But "something" must have still had a disk resource locked. Since I had no idea what that could be, I hard booted the server. After the hard boot the server came back up and initiated a parity check as it normally would after an improper shutdown, and it had the same slowness as the previous time. I stopped the parity check, and used the server. Everything was accessible, all disk shares and user shares were fine. No drive had any SMART errors on them, "that I wasn't already aware of". (I have 1 drive that has had 11 pending sectors on it for 6 months). After using the server for a while, I tried to stop the array and the same thing happened as before. It just got stuck unmounting the disks. Nothing at all changed about my system besides the OS version between the last time I did a parity check with B14 and the partiy check with 6.0.1. I've had the same hardware since December of last year. I use no dockers or plugins. I have screen starting fro my Go. I can remove that easily enough, and will probably try that as a next step when I get home this evening. Otherwise everything should be stock unraid.

I'd pay for Raid-6 regardless of how it's implemented, as long as the cost is not to extravagant And as long as it's a feature you can turn on and off. If the end user has a choice of whether they want to run with dual parity or not, and it's understood what the drive spin up implications are for each scenario. Then whatever. Limetech should implement the one they think will work the best. For people that use cache drives it's just a once a day thing anyway.

I think it's worthwhile mentioning that in this thread, and I think in other threads multiple people including myself have expressed a willingness to pay for dual parity. If it's a time consuming or difficult feature to add, as has been suggested, I don't mind paying for it to make it worth Limetech's effort. Thankfully I've never had 2 drives fail at one time, but I have had single drive failures a couple of times, and the panic of realization that if another drive happens to fail before I can replace the failed drive is horrible. And yes I know that backups are the best solution to this problem, but as others have mentioned do I put out thousands of dollars on putting together a backup server, or do I just spend a couple of hundred dollars on another parity drive. And yes I've heard the arguments where people ask "How much is your data worth". But frankly that math changes dependent on how much money you make and what your other financial obligations are. The other thought that's crossed my mind a few times recently is having a vm unraid backup server running through kvm on the bare metal unraid. This would still be an expensive solution, but maybe not as expensive as putting together a whole new system. Thoughts???

Yeah, I thought about putting it on a hosted service like flickr, but I don't know, the paranoid part of me doesn't like the concept of putting thousands of photos(some personal) on someone else's server. Maybe that's what I'll end up doing...

I'm sure if I dug around for hours on the forum, I might find the technical answers to my question, but I'm also interested in opinions. I'm looking for a good way to browse photos stored on unraid from both a ChromeOS device and an IOS device. Here's the story. My wife takes thousands of photos and videos every year. Occasionally with a camera, but usually with her phone. Whenever her phone's storage gets full, I'll move the files onto unraid for her. I have a user share setup just for her photos, and on her Windows machine I have a drive mapped to that folder. In the past she's been happy to simply browse that mapped drive with thumbnail view turned on in Windows. But she doesn't use that computer anymore. I bought a chromebook for me about a year ago, and she's taken it over. She loves how simple it is, just about everything she does is web based anyway, so it works out great. Between her iphone and the chromebook, she hasn't touched her computer for at least 6 months or more. So anyway, last night I did a large upload for her. At least 5000 files. I showed her how you can browse the folders through the unraid web gui on the chromebook, and on the iphone I used an application called "File Browser" to access files on the unraid server. I've used it before and it met my needs, but for her needs it was very slow and doesn't have a friendly interface. Either solution would be fine for me when I'm doing one off things, but she was not very happy. So I need something for her that is simple to use, and fast. And preferably the same solution could be used on Chrome and IOS. I know there are web based apps that I could install maybe through a docker or a plugin, but I want people's opinions on the simplest way to accomplish my goal, that will also be user friendly for my wife.