Offset for SAS and SCSI devices

[perdrix]

For SATA disks that support S.M.A.R.T. you allow the user to "offset" values to reset the "drive health" calculation to defaults.

I have a SAS drive that has a few thousand Uncorrected Read Errors and Uncorrected Verify Errors in the S.M.A.R.T. log and as a result reports a low Health score of 38%

The S.M.A.R.T. tab for SAS drives shows all the data that it collects from the drive, but it would appear that I can't "offset" any of the values, in particular

Total Uncorrected Read Errors
Total Uncorrected Verify Errors

a) Offset these values as you do for S.M.A.R.T.?, or

b) Reset these values to zero in the drive itself?

In an offline email you sent me back in September 2015 you said:

Yes, I completely understand and agree.

Originally the offsets designed to work with IDE/SATA hard disks, but yes, it would be nice to control the error counters on SCSI/SAS hard disks as well:
as this way it would be possible to acknowledge errors, clear the error-counters and be notified about possible new problems only.

Yes, to be honest, this is already planned - just due to the different detection methods required to access SCSI/SAS hard disks and the completely different way how their status need to interpreted, this feature is a bit more complicated than for IDE/SATA hard disks, so it may require some time.
But I can confirm yes, it will be available in a future version of Hard Disk Sentinel.

I can't find this capability in the current release, but that may be because I'm not looking in the right place.

So is this still "planned" or is it already there?

Thanks
Dave

[hdsentinel]

Thanks for your message, patience and question.

Yes, I can confirm that this feature is not forgotten - just still "planned", not yet available in the current version.
But yes, as recently other users asked, hopefully can be done and will be available in the near future.

[DavidPierson]

Hi,

Firstly thank you for such an excellent product. It recently saved a lot of trouble when one drive in a mirror started throwing many bad sectors (1000+). Thanks to HDSentinel the problem was noticed and solved without loss of data or downtime.

For this issue where a disk has bad sectors and has stabilised. Could there be a way to recognise the existing Health Status as the "stable" level and only highlight if it becomes worse?

For example, in the Thresholds we set the Red/Yellow/Green levels.
Could we override those thresholds for a particular disk.
So if one particular disk is 75% then I would make this disk Green for 75% for Yellow for 74% or less so that I will be warned on new errors.

What I think this would do is:
* avoid the warning popups for the disk when it is within its own Green band
* show a green tick on the main window

If there was a full threshold implementation, then it would also apply to temperatures, giving the ability to customise for known hotter or cooler disks.

Perhaps there could be a "custom thresholds" checkbox in the Configuration/Threshold page, and that would present a Thresholds tab alongside Overview, Temperature, S.M.A.R.T, Information etc.

[DavidPierson]

Regarding my last post, I've just noticed that you already have custom temperature thresholds. (face palm). Maybe the same approach can be used for custom health?

[hdsentinel]

I can confirm that it is already possible to specify custom health threshold for any hard disk / SSD.

Then Hard Disk Sentinel will use that to determine the health level (green, yellow, red) and show the corresponding symbol, issue alert based on that.

This is not in the Configuration window, but can be configured on the Overview page of the hard disk itself: just double click on the Health bar to configure custom health threshold for that particular hard disk drive.

It is available in the latest (4.71) version, listed almost top of the revision page of this version: http://www.hdsentinel.com/revision.php

[perdrix]

Any progress on allowing offset values for SAS / SCSI drives?

Thanks
Dave

[hdsentinel]

Yes, it is already planned in a future version.
Most probably in the following version after the next major release, so can be expected in 2018.