Frank1940

OK I gave it a try and after the unRAID system had rebooted, I had no shares and no GUI. But the Flash drive was available. I had a command line, so I got a diagnostics file which is attached. I thought I had installed it according to the instructions but I did not find the plugin dynamix.disk.io on the plugin page so I assumed that I did not have it installed. I ripped it out the hard way by changing the extension on both the .plg and .txz files of dynamix.bleeding.edge on the Flash Drive. When I rebooted everything seemed to be back to normal. rose-diagnostics-20160914-1613.zip

Any thoughts on the time frame?

List the amount of RAM and CPU. Preclear does require a lot of RAM...

That's is an easy one. There are "?" in the file name. Your question should be "Why are there "?" in the file name?" Device model: WDC WD10EADS-00L5B1 Serial number: WD-WCAU48551976 Looks like the plugin is attempting to underline the dashes in the serial number and text ? After seeing what your drive Model and Serial Number are, I would guess that some part of the file naming procedure has replaced the dash (-) with a question mark (?). Of course, that is a forbidden character in a file name! (The unlined question marks in my original quote was an attempt to highlight what I was referring to. This is the file name --- preclear_report_WD?WCAU48551976_2016.08.31?02:47:53.txt --- that I am referring to as having the problem. You can plainly that there are two questions in it.

That's is an easy one. There are "?" in the file name. Your question should be "Why are there "?" in the file name?"

Look at all of the result for the lines where nr_requests = 4 and 1 in the tests in the first post quoted. How do you explain the difference in results when the nr_requests (for when you thought it was 1) was actually set to 4? Not picking on what you are doing but I am wondering if there are some other variables in the test methodology which have not been considered that are having a big impact on the results that you are getting. Perhaps, you should run the same test three or four times with the same variables and see if you get consistent results!

Isn't the nr_requests setting actually intended for use with transactional servers that are seeing thousands of data requests per second for both reads and writes with the idea of being able to consolidate and order those requests to minimize head thrashing? However, at some point apparently, this searching-and-ordering becomes counter-productive as the CPU time spend processing the queue exceeds the disk operation time. Apparently, at some point, someone decided that 128 was a good comprise number to use for the default. It worked 'OK' for light duty servers and didn't penalize GP computer usage too much. (I found that some folks doing database re-indexing operations talking about sweet spots of 32768 and 65536...)

I assume that you are passing the GPU's through to a VM. Why don't you just look for an application that will display the GPU temperature in the VM's OS?

What is the file system on that data disk? If it is xfs then don't bother! (A nyophtye can easily get into trouble moving files). However, if the file system is reiserfs, there can be write performance issues but these usually occur when a file is written or modified. If the files on this disk fall into that category, they can be moved but as testdasi said, you must understand exactly how to do it and the difference between a disk-to-disk copy and disk-to-share copy. (A disk-to-share copy usually ends up in a disaster...) Setting the 'Minimum Free Space' for a share to a value larger than the current free space on that drive will prevent a new file from being written to any disk without that free space in that share. This is done by clicking on "Share' tab, then on the "User Share" tab. Now click on the Share name to get to the page where you make the change. Instructions are found here: http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Min._Free_Space Scrolling up and down around this section of that manual will provide you with more information on some of the other settings on that page.

What values were used for each test?

Yes, that is correct Yes, I seem to have problems getting all of those terms typed correctly into the message. Good to hear about the md_write_limit not applying to 6.2! You have the right server. The Parity drive is WD RED 3TB and Parity 2 is a Hitachi 1TB. Now, this server is currently running dual parity. (One of a very few, apparently, that are using it!) Dual parity is a very CPU intensive calculation involving (apparently) matrix algebra and later chip sets implemented a new function dedicated to matrix operations which makes it much faster! In fact, with slower (and older) CPU's, the operation becomes CPU bound not IO bound. The modern CPU's (with the new function) can do dual parity checks at the same speeds as single parity! The Test Bed server in question can do single parity at 104MB/s and as you can see the dual parity speed is 64MB/s. I am looking forward to testing your new script for 6.2. I don't need a GUI wrapped version. I am comfortable using the command line so if you want a quick test of a script, I can probably give a turn around in one or two days.

In another thread ( http://lime-technology.com/forum/index.php?topic=51036.45 ), Squid asked me to post up my result from using his modified script to see if the script would change the performance with dual parity. The system used for this test was my Test Bed server (spec's below) running ver6 rc4. Here are the results of the parity check after setting the tunables to the Best-Band suggestions. Event: unRAID Parity check Subject: Notice [ROSE] - Parity check finished (0 errors) Description: Duration: 12 hours, 59 minutes, 20 seconds. Average speed: 64.2 MB/s Important disclosures: (1) md_sync_thresh setting was set to one-half of md_sync_window setting. (2) The md_write_limit was left at the default because there is no place to set it in the GUI. Here are the result of the Parity test with the default setting for ver 6 rc4 Event: unRAID Parity check Subject: Notice [ROSE] - Parity check finished (0 errors) Description: Duration: 12 hours, 58 minutes, 22 seconds. Average speed: 64.2 MB/s The output of the script is attached. EDIT: md-write_Limit was mislabeled. EDIT 2: Parity check speed for single parity is about 104MB/s ver 6 regardless of the release. TunablesReport.txt

Not happening! Mine is showing: 2016.08.18 up-to-date I even restarted the browser (Firefox) and cleared the cache. Here is the output in the Plugin Update Check popup window: plugin: checking tips.and.tweaks.plg ... plugin: checking preclear.disk.plg ... plugin: checking preclear.disk.beta.plg ... plugin: checking powerdown-x86_64.plg ... plugin: checking fix.common.problems.plg ... plugin: checking dynamix.system.temp.plg ... plugin: checking dynamix.system.info.plg ... plugin: checking dynamix.system.buttons.plg ... plugin: checking dynamix.schedules.plg ... plugin: checking dynamix.local.master.plg ... plugin: checking dynamix.cache.dirs.plg ... plugin: checking community.applications.plg ... plugin: checking unRAIDServer.plg ... plugin: checking dynamix.plg ... It has the 'Done' button but I don't see where it has checked for the unRAID OS...

You can ignore that warning. There are no files created hence the "missing" file message. I am still getting this on every reboot. Can it be cleaned up? Thanks +1 Made a update with the correction. So how does one get this update? (I am already on rc4 and checking for updates shows that everything is up-to-date.)

You can ignore that warning. There are no files created hence the "missing" file message. I am still getting this on every reboot. Can it be cleaned up? Thanks +1

@cyriouslydylan Have you modified the original preclear_disk.sh with the following command for use 6.2.X? http://lime-technology.com/forum/index.php?topic=13054.msg481622#msg481622 Read this post and the next one from Joe L. Note that there are two plugins in this Preclear Plugin thread. The Preclear Disk plugin and Preclear Disk Beta plugin. The former requires a shell script to run and the latter does not.

Yes, and I fixed my original post. (and I've used "sed" for over 40 years) Any idea where else on the disk the preclear_disk.sh file could be? I did cd /boot and then typed the sed command, but got a comment "no such file or folder". Any thoughts? Well, mine is in: /boot/config/plugins/preclear.disk That is the Linux path that you will use with the cd command to get you to that directory. You then can execute the sed command string. (If I remember correctly, it is silent when the string works.) While I have installed rc3 on my Test Bed, I have not tried either of the preclear GUI's with it as I don't have a disk to test it with at this time. I am hearing some noise that there may be come other issues...

Yes. But for piece of mind, get a printout of the Main page (and 'Cache' tab, if you have one) of the GUI. Then, go to 'Settings' tab, 'Disk Settings' icon and set "Enable auto start:" to 'No'. Shutdown your old server. Pull all the HD's and Flash Drive and install in the new server. Boot the server, check the GUI and make sure that your parity drive is assigned to 'Parity' and your 'Cache' drive is set to 'Cache, and that you have the right number of data drives. (Data drive positions are not important.) Start the array. Now change back the "Enable auto start:" to 'Yes'. If your experience is like mine was, it will be up-and-running within four minutes after you install the last drive.

See here: http://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Disk_Configuration_Changes You want to study the section entitled "Replace a Single Disk with a Bigger One" The section subsection of the instruction appears to be the case you are describing. If this does not work, post back with your question.

Have you read through this thread: http://lime-technology.com/forum/index.php?topic=48508.0 There are several posts on version 6 cache drive problems and solutions.

If it is any consolation, I saw the same thing. The only thing that I observed is that Disk drive activity light was going off-and-on during the read potion and it was on continuously during the write part. So I assume that there is less overhead in the write operations then in the read (and verify) part.

What version did you upgrade to? Version 6.2 beta series requires that the registration be verified on boot by accessing the unRAID server. (This is is to assure that if they release a beta version that can endanger data, unRAID can stop the system from booting.) You seem to having some issues with access the Internet from your unRAID server. Post up a diagnostics file if you can get to 'Tools', 'Diagnostics' icon.

You might be better served to do a manual upgrade. Here is a thread with instructions on how-to-do-it: http://lime-technology.com/forum/index.php?topic=39032.0 At the bottom of the first post, you will find a link to a upgrade WIKI that has even more information including solutions to about every problem which folks encountered in earlier upgrades. (The simpler your configuration is, the less likely you are to have a problem!) The most important instruction is make a backup of your current Flash Drive BEFORE you start!!!!!!!

Did you modify the preclear_disk.sh file to incorporate the change to work with Ver 6.2.X? You can find the command to do this modification in this post: http://lime-technology.com/forum/index.php?topic=39985.msg477756#msg477756 You use the second one (the one not in the quote). I know this now because I am just finishing up a 3Tb using the modified script using that second command line.

The reason why bit rot is not a major problem is that all of the drive manufacturers know that it occurs and they have error detecting and correcting algorithms that are suppose to check and correct it. If you look at the raw data read error rates, you would quickly realize that large hard drives are not practical EXCEPT for these algorithms... Are there conditions when they don't catch and correct an error? Absolutely, but since we don't have access to exactly what scheme is being used, it is impossible for us to know what conditions will allow an error to slip through. These failures are probably what most people call 'bit rot'. Obviously, if they detect but can't correct an error, the drive will report a read failure. (The manufacturer hopes that latter is the default and not the former for his algorithm!) As an aside, I can remember being exposed to extended error detection and correction schemes in Grad School almost fifty years ago. I never used it after that brief exposure and the state of the art is probably many times more advanced than it was back then...