BRiT

That results in finding the 2 drivers, where one is yet to-be-written. ~# yes ''|perl /usr/sbin/sensors-detect 2>&1|grep -Po "^Driver.{2}\K[^\']*" coretemp to-be-written

FYI: here is the result of the following command that seems to be invoked from the page. As you can see nothing matched on the awk statement. # yes ''|/usr/sbin/sensors-detect 2>&1|awk '/^modprobe/{print $2}' # Now output of "sensors" # sensors acpitz-virtual-0 Adapter: Virtual device temp1: +27.8 C (crit = +95.0 C) temp2: +29.8 C (crit = +95.0 C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +28.0 C (high = +74.0 C, crit = +94.0 C) Core 0: +24.0 C (high = +74.0 C, crit = +94.0 C) Core 1: +25.0 C (high = +74.0 C, crit = +94.0 C) Core 2: +26.0 C (high = +74.0 C, crit = +94.0 C) Core 3: +24.0 C (high = +74.0 C, crit = +94.0 C) Contents of lm_sensors: # cat /etc/sysconfig/lm_sensors # Generated by sensors-detect on Tue Feb 3 17:52:45 2015 # This file is sourced by /etc/init.d/lm_sensors and defines the modules to # be loaded/unloaded. # # The format of this file is a shell script that simply defines variables: # HWMON_MODULES for hardware monitoring driver modules, and optionally # BUS_MODULES for any required bus driver module (for example for I2C or SPI). HWMON_MODULES="coretemp"

I updated to the latest from the plugin settings and now everything is busted. I clicked on 'detect' and waited until that came back. After two minutes the following is shown with absolutely nothing available in any of the drop-down boxes to select from. The Load drivers and Add to Startup buttons do nothing. The only buttons that do anything are Apply and Done.

Try this and see if it helps: wget http://www.lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect -O /tmp/sensors-detect yes ''|perl /tmp/sensors-detect 2>&1|awk '/^modprobe/{print $2}' Tried that and it seemed to be roughly the same time-hole which seems to be the following: Do you want to probe the I2C/SMBus adapters now? (YES/no): Using driver `i2c-i801' for device 0000:00:1f.3: Intel Cougar Point (PCH) This bit should only be done once and only once with results cached until told to re-execute again. It should not be executed on each and every page load.

I timed it a few times and it ranged anywhere from 2 to 3 minutes.

New version of Dynamix system temp is available. This version allows the selection of probes to be displayed in the footer. Also inactive/unused probes are removed from the dropdown menu, making the selection easier. Use the plugin manager to update to the new version. I updated to the latest version of Dynamix SystemTemp and now the Web UI went completely rogue and non-responsive for 10 minutes when I tried navigating to "System Temp" Settings via http://tower/Settings/TempSettings . Eventually it came up and allowed me to make selections. Now when I clicked on "Apply" its sitting non-responsive again for at least 5 minutes. The tailing of syslog only showed these relevant entries: Feb 2 21:05:18 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe Feb 2 21:07:19 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe Feb 2 21:09:21 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe I don'r see anything in the code that may trigger this behavior. This is the only command that can be potentially problematic: yes ''|/usr/sbin/sensors-detect 2>&1|awk '/^modprobe/{print $2}' If you can run it successfully, then I don't have any clue about where the bug is.... Yup, that series of commands is taking a mft amount of time on my system. It might be related to unraid kernel not having the IPMI sensors modules available that i requested be added last year.

New version of Dynamix system temp is available. This version allows the selection of probes to be displayed in the footer. Also inactive/unused probes are removed from the dropdown menu, making the selection easier. Use the plugin manager to update to the new version. I updated to the latest version of Dynamix SystemTemp and now the Web UI went completely rogue and non-responsive for 10 minutes when I tried navigating to "System Temp" Settings via http://tower/Settings/TempSettings . Eventually it came up and allowed me to make selections. Now when I clicked on "Apply" its sitting non-responsive again for at least 5 minutes. The tailing of syslog only showed these relevant entries: Feb 2 21:05:18 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe Feb 2 21:07:19 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe Feb 2 21:09:21 REAVER emhttp: sendFile: sendfile /usr/local/emhttp/webGui/scripts/dynamix.js: Broken pipe

That's not the only non OEM assembler of disk drives. To see such quantity of these so soon is a bit surprising. Seems like Western Digital had a MFT (metric ton) of failures in the 6TB drives area that had to be handled in the secondary market. Maybe it was something with the physical platters that made them unusable as 6TB units but mostly-usable at lower capacities.

Any indication on the relative performance of the drives? Did you finish out any read or write speed tests or even a full cycle of preclear (or faster preclear)?

I have not tried. I don't see the LCCs increasing. I think they are still zero. I was more curious if it would recognize the drive, like if wdidle3 only works on WD drives.

Has anyone with the drive tried to see if "wdidle3" works on it?

Firmware revision string smells like WD, however everything else like physical properties and firmware behavior smells like HGST. Of course, WD owns HGST.

These are from smaller 2TB WD and 4TB Seagate drive and 4TB HGST drive. === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green Device Model: WDC WD20EADS-00R6B0 Firmware Version: 01.00A01 Conveyance Self-test supported. === START OF INFORMATION SECTION === Model Family: Seagate Desktop HDD.15 Device Model: ST4000DM000-1F2168 Firmware Version: CC52 Conveyance Self-test supported. === START OF INFORMATION SECTION === Device Model: HGST HDN724040ALE640 Firmware Version: MJAOA5E0 No Conveyance Self-test supported.

Well damn... I just opened the case up to feel for airflow in the new Norco SS-500 cages. The caddy with the 2TB drives doesn't have a working fan. I have the fan connectors run out from the caddy to a separate power line from a fan-bus controller. I suspect the line to that cage is busted. Before I swapped the cages in, I powered them up in default mode (connected to the Norco cage power plug) to make certain the fans ran. I also tested each cage connected to the fan-bus controller. Everything worked fine. Then I removed the old cages and moved the drives into their new cage. I must have messed something up or a wire came loose on the final installation. I'll know more tomorrow. I'm actually surprise the drives are running as cool as they are with no fan at all (low 30s)!

The current revision of the Norco's have large holes in the metal slot dividers (Pictures of new tray). I think they're up to revision 3 now. One of them was PCB redesign to have softer LEDs and the other was the tray setup. I do wish they had 92mm fans though. But my drives were normally around 29-30 C during typical read-only operations and maybe low 40's during parity checks. They were hitting 50 during the last parity check in the 4-in-3 Stacker cages with 120mm fans. The 2TB drives have certainly aged and showing warning signs. Of the 2TB drives, the WD are now running hotter than the Seagates by 2-4 C. It used to be the other way around 4-5 years ago, and I hadn't changed the cages or layout over the entire time I had them. I just migrated to the Norco cages within the past month. I jumped on the NewEgg deal to pick up 2 of them. This is my first large scale change over the past 4-5 years. I even swapped the Seagate and WD 2TB drive slots around and the WD still run hotter now. I do wish unRAID had a statistical collection system. It would be interesting to see when in their lifetime the drives temps have increased during read-only and parity checks.

Are they all doing this? Or only some of the drives? As I noted above, when temps start to run hotter than they used to, that's a good indication of pending failure. Most of them. They're all around 5 years old. The younger ones are maybe 4. This is why I'm migrating everything over to new 4tb HGST. Preventative maintainence steps. The high Temps only exhibit themselves during the parity checks. During normal serving of movies to the players, the tremps are more reasonable. Could this be an issue with the machine's overall capacity to provide enough airflow? Perhaps a badblocks in read-only mode would provide a model of temperature of the course of a scan. The drives are in Norco 5in3 cages and should be getting plenty of airflow. I have 2 Norco cages in the bottom most of a Stacker 810 case, 3 120mm exhaust fans on top and 1 120mm exhaust fan in back.

Are they all doing this? Or only some of the drives? As I noted above, when temps start to run hotter than they used to, that's a good indication of pending failure. Most of them. They're all around 5 years old. The younger ones are maybe 4. This is why I'm migrating everything over to new 4tb HGST. Preventative maintainence steps. The high Temps only exhibit themselves during the parity checks. During normal serving of movies to the players, the tremps are more reasonable.

Out of the drive failures I've had on my 2TB, it was the Green 5400/5900 rpm drives that have failed compared to the 7200rpm drive that was parity thats going strong. I also noticed during my parity checks the old 2TB 5400rpm units are running hotter than the newer 4TB 7200rpm HGST units. It seems things have changed in the 5 years between designs.

I didn't say they were slow, I said they're slower.

The other item to note is the specs say 5700rpm, which is even slower than the Greens or Coolspins which are typically 5900/5905 RPMs.

Careful with calling it CLI Tools...... It wouldn't be suitable without including finger.

Your GPU virtualization stuff is more geek / nerd than these basic tools. Why don't you change the name of that stuff then? Your proposed name chosen gives no insight into what it contains and it will be referred to for the immediate and indefinite future as people ask how to do basic operation of adding a drive to their array without upsetting the wife or family or to troubleshoot why their array isn't shutting down. Why not name it properly now to avoid seeing it used for the next year or two?

Perhaps a better name would be CommandPack or PowerTools Pack instead of the attempt to be cheeky that can come off as offensive.

Also, all knowledgeable users do NOT WANT the latest version, they want the latest stable version. Don't fix what isn't broken. There are a metric ton of users who want the latest development version , but they lack the skills to fix things when it's proven time and time again that the dev version broke something, usually by being incompatible with some other addon they're running. Just take a look at all the trouble threads about people running latest dev version of Plex and then having issues. Instead of correctly identifying the issue, they instead blame the docker container or the creator, needo. That is exactly the wrong direction to cast the blame at.

The proper way of dealing with this is versioning the docker container. That way the user can get a specific container version and know exactly which version of the container they're getting. Doing anything different is still abusing the docker purpose. One other possibility is having the application version contained outside the container and referenced on startup, so the docker container is merely a runtime environment. Think of pointing the docker to a .deb file and installing it to a host mapped volume called /opt/ that maps into the /appdata/applicationname/opt directory similar to how /config is mapped. The other issue with updating of dockers, as I pointed out in another thread, is the docker.img loop back file will get cluttered and will fill up with the user having no means of maintaining it. The only way to fix that is by deleting the entire docker image and recreating it and readding the containers.