RobJ

Thanks Squid, that explains it. This certainly is not a satisfactory situation, a visible refresh that does not appear to do anything, and a hidden refresh that does make changes but is apparently set too long to be effective. Two independent refreshes that are not in sync... Can't wait to see it! Thanks for all your work here, bonienl!

With apologies, this is my second post here that's not plugin related, but I'm not sure where Dynamix issues should be posted. I'm reluctant to post minor things in the main release announcement thread, and it's probably covered already somewhere in the Defects thread, but I only found bits and pieces related to it here and there (but perhaps the bits and pieces add up to a whole, so old news). Please ignore if you have already fixed this. The attached picture shows all 4 cases of the spin/temp display 'regression', drives that are spinning with and without temps, and drives not spinning with and without temps. Drives 8, 9, and 10 are spinning, forgot to verify spin status of drives 1, 2, and 3. Note: this is just a display problem, not the "drives won't spin down" problem, all my drives do spin down correctly. Refreshing the page never seems to correct the above, not manually through the browser page reload or clicking the Refresh button, or automatically through the page update countdown timer.

I would like to request a few things, hopefully before v6 goes final, but whenever you have time. When viewing a support post, saw there was a need for a SMART report, and went looking, found nice options for viewing various SMART report sections but no way to download a complete SMART report. I imagine it's already on your to-do list, but a button to download it would be nice, listed with the other SMART options. I suggest a file to download named "smart_modelname_timestamp.txt", zipping is not necessary. (A file name without any spaces *may* be a little more trouble free for the newest users.) I went looking for a way to download the syslog and finally found it at the bottom of the Tools/syslog. May I please request that the button be moved to the very top, immediately visible to any user? It is nicely implemented, saves a "syslog.zip" locally, containing a "syslog.txt" with DOS friendly line endings, easy for users to attach and easy for helpers to analyze. The only improvement I could suggest is adding a timestamp to the "syslog.txt" file name, eg. "syslog_20150331.txt". My biggest request though is an enhanced download for troubleshooting purposes, a zipped file containing the syslog, a SMART report for EVERY drive that it can see (in or out of the array), and possibly other diagnostic and log files. Name it something like "servername_timestamp.zip", and add it to the Tools buttons, as something like "Download Diagnostics" or "Troubleshooting". In addition to the syslog and all SMART reports, I would like to see (when you have time to consider it) a text file included (name it "Main.txt"?) that is a text version of the Main screen, containing the same complete layout of all drives and their numbers and status indicators. Include all columns but the View column, and use 3 letter codes for the ball colors (Red, Blu, Grn, Gry, Yel, Ong, etc). By the way, it would be nice to be able to call for the generation of this report from the command line, on those rare occasions when network access is lost, but you still have a working console. Edit: just realized this may not be the right place for this post. Sorry. Will move it where you suggest.

You may be right, I'm going to have to think about that. It was my feeling that many veteran unRAID users would balk at reformatting. I'd like to hear more views, from both fresh users and veterans.

I don't think they are ready to announce it yet, but they have been working hard on it for awhile. By the way, I've now copied a little of yours, will copy more later. Thanks, you are now listed in the credits. You (and anyone else) are welcome to work on it too! Very true, I've mentioned both of those in the wiki page.

Nice work Frank! I've actually been trying to do the same, on the wiki, Upgrading to UnRAID v6, woefully incomplete. With your permission, I may pull a few things from your work? I'll try to give credit, as I'm also planning to draw from the comments of a number of other users too. I'm hoping to make it a comprehensive resource, but yours is already fine for many users, all they need.

HPA's are managed by physical drives, as a supposedly hidden partition at the end of the drive. Your 2x2tb drive is essentially a virtual drive, and I can't think of any reason why Areca would provide support for faking an HPA on it. What would be the point? You can always create a hidden partition yourself at the end of the drive.

I noticed 4 items, but cannot say if any of them are directly related. I can confirm what you have said, preclear of sdg is apparently successful, but is not identified as cleared. I suspect the problem with the Parity drive is 'confusing' UnRAID. * BIOS is a little old, from 2010. Syslog shows a number of ACPI workarounds, a little more than normal. If you can find a newer BIOS for that board, it *might* help. * You have IDE emulation turned on for 2 of your SATA drives. When you next boot, go into the BIOS settings and look for the SATA mode, and change it to a native SATA mode, preferably AHCI if available, anything but IDE emulation mode. Performance to Disk 3 and your Cache drive should be slightly faster, and a little safer. * You have stations all over the web attempting to connect to your machine, so I have to assume you have it set in the router's DMZ (sic?). Most failed, but some telnet attempts appeared successful, both local and from outside your net. A serious sniffing attempt was made from 42.116.99.53, using various user names and ports. I'm not an expert here, but this sounds incredibly dangerous! * Parity drive (sdh) is not configured correctly. It is a 4tb drive but is configured for 2.1tb, as if >2tb support was not available when drive was prepared. Usable space on it is 1.99tb, usable space on the true 2tb drives is 1.81tb. On array start (each time), the system appears to recognize that something is wrong, and rewrites the GPT entries to the Parity drive, reports unknown partition on it, but does NOT proceed to build parity, apparently accepts it as correct! When you added the new drive as Disk 9, the GPT entries were again written to sdh (the Parity drive), then an MBR written to sdg (new Disk 9). It's possible the GPT writing to sdh caused an execution path that bypassed the already precleared test for sdg. Perhaps the discovery of unknown partition on sdh set a flag that affected the testing of sdg. You might email Tom and link this post.

Can you attach a zip file of all the preclear reports? I'm afraid I won't have time until evening, but someone else may. Hi Rob! Thanks for getting back to me. Attached are the pre_clear reports. Some are older. The drive I was trying to clear is /dev/sde No problems at all in any of the preclear reports. Drive is perfect, and correctly precleared. I'm out of ideas. DO you happen to have the syslog for the session where it rejected it? Perhaps a clue will be there. If no syslog from then, would it be possible to try adding it again, and grab the syslog after, and attach it here?

Can you attach a zip file of all the preclear reports? I'm afraid I won't have time until evening, but someone else may.

Thank you for that. I've updated the Setting up CPU and board temperature sensing wiki page with your info. Please feel free to edit, expand, and improve it. bonienl, I also updated the Perl info on the page (in Step 6), but I'm not positive on the Perl and Slackware versions, or the V6 support as to the whole page. When you have a chance, could you look over the page and either make any corrections and improvements, or suggest them to me?

You have only mentioned a single segfault, what other errors have you seen? By the way, without knowing your hardware, I'd stay with the simple Preclear command, without the -b, -r, and -w options.

The V6 section doesn't seem to have a Plugins board. Would you prefer the Plugin Design board in the Development section? It seems to have a number of other V6 plugins.

Joe L, there's a bug in Cache_dirs, primarily affecting users with the -w option and no includes, no -i option. I discovered it when comparing syslogs from the same user (and confirmed after viewing a number of other syslogs), where Cache_dirs would start at differing points of the drive mounting process. In one syslog, Cache_dirs initiated during the mounting of Disk 10, within seconds of the mounting of Disk 1, resulting in a cached directory list of 3 folders, what it found on the first 9 disks only and not the Cache drive. In another syslog of the same server, it initiated after the last drive and the Cache drive, resulting in a cached list of 7 folders. When it initiates, it builds a cached directory list from what it can find at that moment, and never checks again until restarted. I don't fully understand the problem (because I found exceptions), but it appears that the "at now + 1 minute" is the cause. I assume someone thought that the "now + 1 minute" meant one full minute from now, but it actually means schedule it at the top of the next minute, which could be only seconds away. So most Cache_dirs (but not all) are started at the top of a minute (eg. 17:48:00, not 17:48:13). The simple way to fix that would be to change the command to something like "at now + 2 minutes", which would result in a minimum of 60 plus seconds. My preference however would be 3 to 5 minutes, in case of long transaction replays. A better solution though would be to test for the disks_mounted event, which occurs after all array disks are mounted, and the cache drive mounted, and the User Share system setup. Since mounting is rather quick, this problem has probably not affected many users. It should only affect users with a longer mounting time that started near the end of a minute. After examining a number of syslogs, I would like to strongly recommend always using the -i option, to limit the folders cached to only those truly desired. Using the -w option alone results in ALL top level folders on all array disk being included PLUS all top level folders on the Cache drive. I saw a number of cases where almost certainly unwanted folders were being cached, which wastes memory (especially in 32 bit versions), and may cause the desired directory entries to be flushed out occasionally.

You are trying to thoroughly test the drive, so cutting back on the testing seems a little counter-productive, but yes the preread is the least useful part of the testing, so skipping it shouldn't affect the result and would save time.

It means the drive tested each of the 8 sectors, when written zeroes to, and decided they were fine so put them back online. It doesn't mean those 8 are perfect, although they could be, but for now the drive believes each of them can be trusted. The drive appears to be fine now, but not perfect. The best advice we give users when this happens is to Preclear it one or two more times, and see if anything changes. If no further changes, then the drive should be good. All other numbers look OK.

Nothing to worry about, at all. I've made some suggestions to Joe L about removing these near_thresh's from the reporting, but I suspect he's been too busy lately.

It takes time to understand SMART reports, and the inconsistencies within them. For the error rate attributes, the important number is the VALUE, which for both is perfect at 100. Their RAW numbers are internal use only, ignore them. For other attributes, the RAW numbers are sometimes useful, but you have to understand how each attribute is used. They are all different.

Not necessary. It's been a looooooong time since that had to be done!

What is the significance of installing in /boot/plugins? Does it affect the way that the plugin operates? As far as I can tell, it is only a simple way to control timing. Some things have to be installed before others. So far, it only appears to have been used to load base plugins, the platforms upon which other plugins will install. The distinction 'system' has so far just meant that it should load before other plugins. Tom, dlandon, and others may know more though.

High-fly-writes don't have a threshold or valid scaling routine. The RAW is an actual count of how many high-fly-writes have occurred, but VALUE is just 100 minus the count in RAW until it hits one where it will stay. It never reaches zero, but the RAW count will continue to increase. The THRESH number is zero, which basically means it is not used, since it cannot be reached, which also means this attribute can never FAIL a SMART test. Joe's point is good though. 77 high-fly-writes already (only 50 operational hours) is rather unusual, so probably something to monitor. However, I do not know of a single case where a drive failed with a very high or growing high-fly-writes count, so it does not seem to be a significant item. It was added several drive generations ago to the SMART attribute tables of many drives, but always with the same dummy scaling routine, and always with a THRESH of zero. I prefer to call it an experimental attribute, perhaps one they wanted to monitor to see if there was any association with drives failing. So far, I haven't seen one, and the fact the handling of it hasn't changed seems to indicate it's not an important factor to them either. I would use the drive without any concerns. There are no other indications of issues at all.

I was going to suggest a wheel chock, but it's too low. Another possibility, more practical, use it as a decoy for thieves. Set it on an appropriate shelf, visible, with a label indicating "All my financial info", and underneath that the word "(hidden)" to totally interest any hacker. Load it with gigabytes of trash videos (any kind) and other garbage, and that should give you a big laugh if it is ever taken. It is really really time-consuming and frustrating trying to recover data from a bad drive, especially if it is getting worse while you work on it. Or for the less technical thief, label it as "Very private videos, hidden on here". Should waste a lot of their time.

Drive is fine. Final temp is 33, nothing wrong with that.

Yeah, lots of bad sectors. I would start a Preclear but skip the Pre-read (use preclear_disk.sh -W), since you already know there are issues. The write-zeroes phase should force the drive to deal with every sector, remapping them if necessary. It will probably be slow. Then the Post-read will test the drive, provide a final SMART report, with hopefully all Pending sectors fixed. From the last report and the Preclear report, you should be able to decide what to do with the drive. I do apologize for my tone above, somewhat myopic, only looked at the one post.

Edit: I apologize, I've just noticed elsewhere that you have included a syslog. [respectful chide mode on] It was hard to know how to respond. You have a drive that had been red-balled, and was now running extremely slowly, and yet it does not appear that you thought to check or include a SMART report and the syslog, which would normally be stuffed with reasons for the problem. I do understand this may be your first drive issue, but it still was very disappointing. I'm not blaming you, those of us who are veteran UnRAID users, including LimeTech staff, have to take some responsibility for not doing a very good educational job. We need to do a much better job making sure ALL users, both new and experienced, know what a syslog is, why it's so useful, and how to capture it, and the same with SMART reports. They are admittedly hard to interpret, but there are many here ready and willing to help with that. If we had done a good job, and a problem like this arose, every users first thought would be "something is wrong, let's see what the syslog says". Perhaps we need more stickied troubleshooting help posts. Perhaps the initial ReadMe needs an 'UnRAID Troubleshooting 101' section... There have been a number of cases like this lately, where the syslog was needed yet the user never thought of it. This too was disappointing. It's like someone has a shed on fire, and someone else says "I wonder if that strange foreign family down the street did this", leading to rumors and distrust. Please don't cast aspersions on something without a single shred of evidence. Beta 9 is working fine for most, and I don't know of any reports of slow drives with it, and slow drives are a relatively common issue. I'd venture to say that at this very moment, around the entire world, there are hundreds of thousands of very slow drives occurring, using many different operating system versions. Many of them are problems with the drives, and the others are problems with the interface to those drives. A syslog or comparable diagnostic will clarify the issue. [chide mode off]