gfjardim

It's harmless and will be squashed in the next release.

Guys, this is why we have to take a look into all important SMART values in every cycle before adding a disk into the array: And more important: why we should run more than one cycle on each disk.

Which version of unRAID you're using?

Thanks for this advice which solve my issue like abhi.ko was having. For some reason this was not required when I installed it on my other server with 6.2 beta20. Password was required when I tried to install it on main server with 6.1.8. All setting in 6.1.8 are required when you use a default template. In 6.2, every field can be set to be required or not. Just to be safe, I removed the vnc password from 6.1.8 part of the template.

Snapshots would be great at preventing this, but I won't use BTRFS with my valuable data anytime soon.

When I studied Joe L. code, I realized that the primary function of the original script was, for a long time, to detect malfunction in hard drives. Little coding is needed to clear and write the clear signature. In fact, it can be done with less than 40 lines of code. All the remaining code is to make a pleasant user output, retrieve and compare SMART attributes, generate reports, avoid wrong disks from being cleared, stress the disk headers etc.... Of course I'm open to any suggestions. We can easily add other methods to complement those in place. If you can point me the proven badblocks tests we could add, that would be great. But I would never add a disk to my array before I took a good look into it's SMART attributes, and that kind of awareness is not officially offered yet. These are my favorite versions of badblock commands - - Read-only method: badblocks -b 4096 -c 256 -sv /dev/sdX - Destructive read/write method: badblocks -b 4096 -c 256 -wsv /dev/sdX - Non-destructive read/write method: badblocks -b 4096 -c 256 -nsv /dev/sdX Each of the above use 4K blocks, in 1MB segments. Add an option for a SMART long test in there, and you are close to my proposal (last paragraph) a while ago. I still like my idea, for user controlled strategies. This program has a lot of caveats, like its output; there's no reliable way of retrieving the speed or how many blocks it had already read.

Ok.. What did I miss? I haven't been following too closely.. Did limetech do something in an update that changes how we add a drive? Jim Yep, the array will remain online while the disk is zeroed in the background.

When I studied Joe L. code, I realized that the primary function of the original script was, for a long time, to detect malfunction in hard drives. Little coding is needed to clear and write the clear signature. In fact, it can be done with less than 40 lines of code. All the remaining code is to make a pleasant user output, retrieve and compare SMART attributes, generate reports, avoid wrong disks from being cleared, stress the disk headers etc.... Of course I'm open to any suggestions. We can easily add other methods to complement those in place. If you can point me the proven badblocks tests we could add, that would be great. But I would never add a disk to my array before I took a good look into it's SMART attributes, and that kind of awareness is not officially offered yet.

I would suggest leaving it blank for unchanged. Would make it more obvious exactly which values should be examined further. Also then you do not need to actually say it has changed - just include the details. Well, I do agree it looks cleaner. What do you guys think? ######################################################################################################################### # # # S.M.A.R.T. Status # # # # # # ATTRIBUTE INITIAL CYCLE 1 STATUS # # Start_Stop_Count 4991 4991 # # Reallocated_Sector_Ct 0 0 # # Power_On_Hours 24879 24893 Increased '14' # # Runtime_Bad_Block 2 2 # # End-to-End_Error 31 31 ->FAILING NOW!<- # # Reported_Uncorrect 0 21 Increased '21' # # Command_Timeout 4 4 # # Airflow_Temperature_Cel 44 42 Decreased '-2' ->Failed in Past<- # # Current_Pending_Sector 0 72 Increased '72' # # Offline_Uncorrectable 0 72 Increased '72' # # UDMA_CRC_Error_Count 0 0 # # # ######################################################################################################################### # SMART overall-health self-assessment test result: PASSED # ########################################################################################################################?

* For consistency with every where else in unRAID, I would prefer the attribute numbers visible. * In my opinion, I don't think you need the Status column with changed/no change, as we can all see the changes or lack thereof. * Temps can be found in 190 or 194. Some drives only use 190, some only use 194, many use both. You could look for 190, if not exists use 194. * The over temp message "Failed in past" I've only seen a few times, seems harmless, just means temp hit high temp threshold at some point in past. I don't think I have seen that "Failed in past" on any other attribute, but I suppose it's possible. I don't think it's necessary to display it. * 4 Start_Stop_Count is quite unimportant. I don't think I have ever seen it associated with a single drive issue. If you want it, then you should probably add 12 Power_Cycle_Count, 192 Power-Off_Retract_Count, and 193 Load_Cycle_Count, so the user can see the relations between them. But these are all non-critical, won't fail the drive. * I know you've selected a set of attributes to open the discussion. I personally would prefer seeing as few as possible, keep it clean and simple, to avoid confusion. Showing 9 and 190/194 gives a nice time and temp history, and 5 and 197 display the most critical items concerning bad sectors. And it's always nice to show any significant change to 199, so you can warn them about SATA cable quality. But I think that more than that isn't necessary, unless the attribute is important and changes significantly. * The only critical attribute you have chosen is 5 Reallocated_Sector_Ct. Only critical attributes can fail a drive, those with a flag value with the one bit on, those that say 'Pre-fail'. I believe the ones most likely to fail a drive are 5 Reallocated_Sector_Ct, 1 Raw_Read_Error_Rate, 7 Seek_Error_Rate, and 3 Spin_Up_Time. For all but 5, you would want to display the VALUE, not the RAW. * If you are sure you want 188, be aware that some drives have it as a single small number, but some Seagates have it as a set of 3 small numbers, a 48 bit value that should be treated as 3 16 bit values. If it's a huge number, break it into 3 numbers. * A number of those attributes won't exist on some drives. * Not used to seeing a drive go through multiple Preclear cycles and not age a single hour! * At some point, you may be asked for an SSD Preclear option, which could be just a zeroing plus signature plus SMART display and evaluation, no pre or post reads. The SMART attributes for SSD's are generally very different, and the age and wear level may be the most interesting ones (but very inconsistent attribute numbers). * 'ATENTION' should be 'ATTENTION'. 1) It's easy to add back; 2) I somewhat facilitates the job, so I'm leaving it; 3) Yes, I know. It's being triggered when a fan failed last year; 4) Ok, Start_Stop_Count removed. 5) I'll take a special look into those attributes; 6) Sometimes, other attributes may failed the drive, e.g. http://lime-technology.com/forum/index.php?topic=47764.0 . It's a work in progress, so we should add those related to failure, being pre-fail or old age. 7) I'll remove 188; 8 ) Yes, I know. I will show only those that exist on the clearing drive; 9) It's a "short test" function that reads/writes only 1 GB of data each cycle. Do you think that I wait 120 hours to test a cosmetic change? 10) It's already in place, just skip pre read and post read and you're good to go. It won't try to stress a SSD header too. 11) Nice catch. Didn't had the time to search for typos/misspellings yet. Thanks a lot for your input!

I use the ID's as a whitelist. Currently, these are the current whitelisted id's: 4 5 9 183 184 187 188 190 196 197 198 199 The 9 (Power On Hours) and 190 (Airflow Temperature Celsius) are just for testing.

Hi guys, what do you this of SMART report? Anything missing?

Does that mean you can stop the array during a preclear . Add additional hard drives and restart the array and the preclear will resume ? This does NOT Mean you can reboot the system ? It will pause all current clearing sessions while the array starts and stops. If you reboot the server, all progress will be lost.

gfjardim Thank you for the update You can disregard the previous request for help as the latest update fixed the error message. Do I still need the added line .... mount -o remount,size=256m /var/log......in the Go file ? If you have spare RAM memory, then better you leave it there. Lots of plugins use that directory for logging.

[glow=red,2,300]Update to Beta:[/glow] 2016.03.22 - Fix: Better S.M.A.R.T. report - Add: Save a report in /boot/preclear_reports 2016.03.21 - Add: pause any preclear operations while array start/stop - Add: Initial SMART reporting

waited a few days, this repository appears to still be broken. Works for me. I click on the link in your post and it downloads. Why not host the packages in your github repo? Would eliminate the possibility of any broken links. No need. Oregon State University is rock solid: http://slackware.osuosl.org/slackware64-current/slackware64/l/parted-3.2-x86_64-2.txz

waited a few days, this repository appears to still be broken. Works for me. I click on the link in your post and it downloads. Probably your mirror is different from his.

You cannot run preclear against any drive that is assigned to the unRAID array. I assume that you currently have the drive in question assigned as parity? I found this bug other day by accident. If you remove your parity drive from the array, it still doesn't appear on the plugin main page. Please update your plugin and try again.

waited a few days, this repository appears to still be broken. Try this one: http://linorg.usp.br/slackware/slackware64-current/slackware64/l/parted-3.2-x86_64-2.txz

No idea on what's happening. It's being an era since I updated this container, and I'm considering deprecating it. I do recommend you to migrate to Linuxserver's one. Best regards.

That's expected since the Beta version has a lot more logging, not just errors.

Your /var/log directory is full. If you have enough RAM, you should run this command: mount -o remount,size=256m /var/log Add that to your /boot/config/go file to make it persistent.

There's a HTTP instance opened on port 8001.

Probably the server rebooted.

gfjardim ... was that reply for me? If so i do not understand what you are trying to tell me. I do not have a preclear disk beta tab within settings. FYI i downloaded the 'amended' version by 'search'ing for 'preclear' on the CA apps tab. It downloaded the new version (dated today) and the install script confirmed this but the plugin it installed still shows old timestamps and version number against it and hasn't got 'beta' anywhere to be seen. You know much better than me how these things work. I'm just happy to confirm that it does!! Seeing a reply to a deleted post was initially confusing but now I'm curious as to how the beta Pre-clear plugin is incompatible with the Unassigned Devices plugin, since this is the first time I've seen an incompatibility mentioned and because I have both installed. He didn't saw those Preclear icons in Unassigned Devices, and that is an expected behavior since the beta plugin's path is different.