Frank1940

I think you are going to be waiting a long time. Think of it this way. There is a long freeway with two lanes of traffic in each direction and a speed limit of 70 miles per hour. In the middle of this freeway there is a construction zone that is serviced by a one-lane section with traffic in both directions and a speed limit of 35 miles per hour. That is essentially what you have when you put a server on WiFi. With minimum traffic, things will run relatively smoothly. With a high traffic, things will virtually grind to a halt. Any mix of traffic in between will be a mixture of these two scenarios. I think any alternative (in the future) that you seek is going to be going to be a replacement for both WiFi and Ethernet. But I have not seen anyone even propose a possible theoretical idea of how such a system might work.

If it locks up again, you could install the 'Tips and Tweaks' plugin. Then goto the Tweaks page and set the Disk Cache 'vm.dirty_background_ratio' (%): parameter to 1 and the Disk Cache 'vm.dirty_ratio' (%): parameter to 2 This will free up a big block of memory without any observable effect on performance. You can read a bit more about these parameters by clicking on the Help function.

I didn't have to flash mine as I purchased it already flashed but the procedure that you linked to looks correct. I would print it out and read (and reread) it until I was really familiar with it. Then I was was doing it, I would check off each step and double verify that the screen responses were actually as described before moving on to the next step. I do know that my card was flashed to the P20 software and it has functioned flawlessly.

The E6600 should be up to the task. How much memory do you have installed? It takes between 2GB and 4GB of RAM with ver-6.3.5 to have a system that is not RAM constrained if you are only running the basic NAS function, the 'usual plugins', and perhaps, a Docker or two. The preclear function does require a fair amount of RAM so that might be an issue.

You can start by looking at the two threads below or googling Flashing LSI SAS9211-8i to IT mode. https://forums.lime-technology.com/topic/11753-sata-controller-cards/ https://forums.lime-technology.com/topic/12114-lsi-controller-fw-updates-irit-modes/ Thanks @johnnie.black I didn't realize that the procedure was easier for the genuine LSI boards than for the OEM sourced ones.

Sorry, but it will have to be cross flashed to IT mode.

Usually, Attribute 199 errors are attributed to the SATA cable. (Not a Hard Drive issue) Replace the cable first and see if that clears up the problem. Also, don't tie SATA cables together to make things 'neat' inside the case. SATA cables are very prone to cross-talk which is a principal cause of CRC errors.

Post up the model number of the card. If it is genuine LSI card, there is a possibility that it already has the IT mode firmware installed. Most of the used cards are not in the IT mode but rather have the RAID firmware.

The only problem I can see with this request is that you have to login to the GUI as root and from the GUI you can do virtually as much damage as you can via SSH. (I can quickly wipe out the data on the entire array by changing the format on each drive from (say) XFS to Reiserfs.)

Yes, IF the firmware has been upgrade to the IT mode.

I used google and found this as one of results: https://access.redhat.com/solutions/30453

Have you made one of your unRAID servers the Local Master? This could resolve your issue entirely-- Particularly if your server is on 24-7. (SMB is is part with-craft and smoke-and-mirrors. Sometimes it takes of bit of both to get it work correctly!) Have you read through this thread? https://forums.lime-technology.com/topic/53172-windows-issues-with-unraid/ Be sure that you look carefully at the sections where you can determine exactly what computers are a part of your SMB network from the computers that are having the issue. Also double check that all SMB resource references have the same name and that you use CAPITAL letters when you name them. Capitalization is a big deal when one in dealing with combined Windows and Linux/UNIX OS operations because Windows ignores it and Linux/Unix honors it. Thus, Test.txt and test.txt are the same file to Windows and two different files to Linux/UNIX. How SMB resolves this issue is a real headache!

I think your wording is better than mine and it very big improvement on the original which will clarify exactly what will happen to any process that is listed to anyone who has not seen the postings about the problem which prompted the inclusion of this functionality.

A suggestion on wording of this new feature. Rather then calling it "Processes to kill when Array is Stopped:", I would calling it: "Processes to kill when Array is Being Stopped:" (I interpreted the purpose of this new addition from its name was to kill processes after the array was actually stopped. But after looking at the new function and the 'Help' on it and knowing a bit of background about the reason that it had been requested, I believe it actually either (1) runs before the Stop Array starts or (2) a predetermine time after the Stop Array has started.)

If this proves to be the solution to the OP's problem, could you add a post to this thread: https://forums.lime-technology.com/topic/53172-windows-issues-with-unraid/ And include links to this thread and to the entry in the WIKI. I have a feeling this will be the first of many posts about this type of problem as MS tightens overall security on Win10.

Krusader also works with Chrome. So the issue is definitely Firefox related.

Same problem with 56.0.2! Has anyone else seen this?

An issue--- Krusader does not work with Firefox 56.0.1. It does work with Internet Explorer. When I start the "WebGI" , it opens up the new browser window and then the windows goes black with a second. Same issue on both of my servers. I have attached a portion of the log file from my most recent attempt to use it with Firefox. I will be trying this again as soon as Firefox is updated. KrusaderLog.txt

There already is a heck of a lot of error checking on any modern hard drive. If you want to have your head spinning just do a Google search on 'bit rot'. Personally, I feel that 'bit rot' is more of boogie man than a real life problem. With the amount of error detection and correction already incorporated into modern hard drives, a drive in constant use will probably fail for other reasons before bit rot causes a problem. Now if you are going to load up a hard drive and put it in a closet for twenty-five years, bit rot may be a problem when you go to read it. You now have one opinion... PS--- A couple of years ago, I found some data on raw read errors provided one of the HD manufacturers and did some analysis on it. I was shocked to find out how often they can occur. As I recall, you get several of them EVERY time you do a parity check if you have an array with more than three drives in it. BUT, you never see them BECAUSE the drive error detectio finds them and the error correcting software then corrects them on the fly.

turn on the 'Help' when looking at the settings for disk caching, Notice what the Help says about " Scan user shares: ". If you are scanning the User Shares, you may be increasing the the amount of memory needed for storage by duplicating the the same info as was in the default disk caching.

What I suspect is happening (Completely a mental exercise on my part) is that contiguous blocks of memory are set aside as the OS boots up for the use of these two parameters. Now do a bit of math and you will see that with large amounts of installed RAM, this is a huge number. As you continue to use your server, the the available RAM becomes more and more fragmented over time. Eventually you get to the point where some process requires a block of RAM that is larger then any currently available. Now the OS throws out an OOM warning and selects a process to kill to get more RAM. As long as the process being killed is not necessary at that point and restartable at some later time, all is fine. (In the past, what would occasionally happen is that it would kill off the process that runs the GUI if the GUI hadn't been accessed for a long period of time. Unfortunately, the GUI process that unRAID uses is not restartable and that was a big problem! BTW, the function that these two parameters provide are largely unnecessary because of the way unRAID is generally used and the faster speed of modern hard drives. (In fact, I believe many modern HD's, with their on-board memory and controller, basically do the same function that the process that uses this memory does.)

Did you add that XFS disk as a part of the array? If so, you can't use it to rebuilt the failed disk onto. You will need that new disk to do a rebuilt.

IF that disk were physically offline, the whole process could go much faster but I am unsure how to do that and not screw up something else. You could stop the whole process and physically remove the disk from the array and do the copy again using the virtual disk. As a point of data security, do you have another disk that you could use to rebuilt the failed disk? That would allow you to use that XFS formatted disk as a secondary backup which would protect the data already copied until you were sure that the rebuilt was successful. I think you have two choices at this point. Which would be the "better" choice is a matter of conjecture at this point. 1--- Stop the process and physically remove the failing/failed disk (Giving you a missing disk) and restart the entire copy process to the XFS formatted disk. 2--- Use that current XFS disk to rebuilt the failing/failed disk onto. EDIT: This will not work if the XFS disk is a part of the array!

I believe it tries the failing disk first and then reconstructs the data from a parity calculation. That is why the process is so slooowwww.

I would think you would be better served to start a new thread about your problem. While you might be using the method suggested in this thread, you issue is not about the actual process but more a hardware failure. If you have only one disk with a problem, you have not lost any data at this point. But you do need to seek some advice on how to proceed from here...