Disk Diagnostic Warnings

Peter H

Member
What data determines the warning output (pink square window)?
I looked at the "fix-disk" script but do not understand most of it!

There was a warning when doing disk diagnostics which I acknowledged, when retested after a couple of hours, "re-located sectors were rising" so replaced it with a spare disk.
I then used" smart" on a Linux PC and it passed, so will not throw it away until I am sure its failing.
My original problem was intermittent pixelation which has stopped since I swapped HDD, so it may still be faulty!

I had assumed that after acknowledging the warning, it would calculate errors from that point, is that how the CF functions?

Thanks
 
What data determines the warning output (pink square window)?
...
The Webif on HDR models runs the smartctl utility to discover the current values of 6 parameters for the internal disk. It stashes these in the settings database. If any values are "worse" than the previously recorded values (in particular, than those previously acknowledged by the user) it displays the "pink square window". Fix-disk is a separate thing.
 
There was a warning when doing disk diagnostics which I acknowledged, when retested after a couple of hours, "re-located sectors were rising" so replaced it with a spare disk.
Please can you show us the output from the disk diagnostic? Take a note of the number of reallocated sectors and after the box has been on for a few hours check again; if it is rising over a few hours then the drive is, in my view, probably close to end of life.
I then used" smart" on a Linux PC and it passed, so will not throw it away until I am sure its failing.
Please could you tell us how you used SMART?
My original problem was intermittent pixelation which has stopped since I swapped HDD, so it may still be faulty!
I deliberately ran an HDR-FOX T2 with a failing hard drive, which had got to the state where it was reallocating sectors quite frequently and there was a very noticeable on screen glitch which could be tied to a sector being reallocated.
 
...
I deliberately ran an HDR-FOX T2 with a failing hard drive, which had got to the state where it was reallocating sectors quite frequently and there was a very noticeable on screen glitch which could be tied to a sector being reallocated.
To be clear, do you mean that you were actually able to tie some display glitch to a specific reallocation, or that such a tie would be plausible?

From experience, though not deliberate, I do confirm the general observation that a failing disk can be linked to display glitches: ie, glitches started when the disk was failing and stopped after it was replaced.
 
The suspicion is that the extra processing overhead when a disk write error occurs interrupts necessary processing for maintaining the live output.
 
To be clear, do you mean that you were actually able to tie some display glitch to a specific reallocation, or that such a tie would be plausible?
I was noting the value of reallocated sectors at the start of watching a programme, making a mental note of the number of glitches and then looking at the reallocated count at the end of the programme and there was pretty good correlation.
 
The Webif on HDR models runs the smartctl utility to discover the current values of 6 parameters for the internal disk. It stashes these in the settings database. If any values are "worse" than the previously recorded values (in particular, than those previously acknowledged by the user) it displays the "pink square window". Fix-disk is a separate thing.

OK thanks, I was wondering if the CF noted the data and if it was only worse by one count would it be flagged up or only if it exceeded a certain amount for each parameter as it kept giving the warning.
It was just to get a feel as to how it worked, more important is to determine if the HDD was the problem as it only has 9000hours run!
FWIW problems are on recordings up till 22nd Sept (Wenvoe Transmitter) but seems to be OK on recordings since I replaced HDD, will wait another week before deciding what to do.
 
Please can you show us the output from the disk diagnostic? Take a note of the number of reallocated sectors and after the box has been on for a few hours check again; if it is rising over a few hours then the drive is, in my view, probably close to end of life.

Please could you tell us how you used SMART?

I deliberately ran an HDR-FOX T2 with a failing hard drive, which had got to the state where it was reallocating sectors quite frequently and there was a very noticeable on screen glitch which could be tied to a sector being reallocated.

I used SMART from my Fedora 30 PC with "smartctl -a" using the Pipeline HDD in a caddy and got the output as per attached file which I have just repeated.
I have now had an old drive from my Digital stream running without problems for 4 weeks but from my limited knowledge cannot see any significant problems other than old age, but maybe others can!?
It is possible there was transmitter a problem around 22nd September (Wenvoe) but the Humax box was giving the warnings.
 

Attachments

  • smartctloct19.txt
    5.8 KB · Views: 11
I used SMART from my Fedora 30 PC with "smartctl -a" using the Pipeline HDD in a caddy and got the output as per attached file which I have just repeated.
I have now had an old drive from my Digital stream running without problems for 4 weeks but from my limited knowledge cannot see any significant problems other than old age, but maybe others can!?
The reallocated sector count of 982 is quite high. What matters though is whether the reallocation occurred a long time ago and is no longer increasing or if it is currently increasing, what the rate is.
 
The reallocated sector count of 982 is quite high. What matters though is whether the reallocation occurred a long time ago and is no longer increasing or if it is currently increasing, what the rate is.

Thanks for the confirmation of my thoughts, it just seemed a little odd that the run hours are quite low. I paid a little over the odds for the box but it is in vgc and the security tab on the base was intact.
The rate was increasing quite quickly and, as "er in doors" wanted the recordings, I decided to change it and as I do not have any problems I will be getting a new HDD in the near future.
 
it just seemed a little odd that the run hours are quite low.
In my experience the ST31000424CS is less robust than the later Seagate drives. My ST31000424CS failed (reallocated sector count was approaching 1500 and increasing rapidly). the 2TB Seagate ST2000VM003 has zero reallocated sectors after something like 25,000 hours.
 
If your're not using the suspect disk and caddy for anything else you could leave the disk on a badblocks -b 67108864 -n -t 0xFF -t 0 -s soak test from the PC (probably a better idea than using the HDR, but still many hours ). That might flush out any undetected badness. If you actually want the sector numbers affected, use physical block-size (512, 4096) instead of 64MB as in the example at the cost of many additional I/Os

Supposedly writing 0s to a pending sector (marked as potentially bad by the disk firmware) will force its relocation.
 
If your're not using the suspect disk and caddy for anything else you could leave the disk on a badblocks -b 67108864 -n -t 0xFF -t 0 -s soak test from the PC (probably a better idea than using the HDR, but still many hours ). That might flush out any undetected badness. If you actually want the sector numbers affected, use physical block-size (512, 4096) instead of 64MB as in the example at the cost of many additional I/Os

Supposedly writing 0s to a pending sector (marked as potentially bad by the disk firmware) will force its relocation.
Martins experience is interesting and seems to be similar to mine.
Even though I have been using Linux for quite a few years I am not experienced in running checks but if someone could explain the commands, I can run it to confirm the disk is beginning to fail.
I assume that if I run SMART, it should show increases but how long would I need to run it to get meaningful output (I do not want to leave the PC running for days)?


Thanks
 
Back
Top