SOLVED: The CF causes processor overload UNLESS fixdisk used to optimise hard drive again

I usually leave fix-disk to run overnight - the actual run length is unpredictable
I dont think it hurts to interrupt but you would have to restart at the beginning there is no Resume option
 
MymsMan said:
I usually leave fix-disk to run overnight - the actual run length is unpredictable
Click to expand...
Agreed. You need to specify "Y" when prompted for additional options at the start of a fix-disk run to ensure that the process doesn't just stop and wait for confirmation at the first error it detects.
I dont think it hurts to interrupt but you would have to restart at the beginning there is no Resume option
Click to expand...
I agree that stopping it won't be disastrous and I think any repairs it has made will remain so the next run should be a bit quicker.

My guess is that there isn't much wrong with the file system on the OP's box so I would be hopeful that the run would complete overnight.
 
If there are bad sectors that can't be recovered and have to be remapped, halting and re-running fix-disk will mean that files affected by bad sectors only found in the first run won't be listed in the final output.

To avoid this, don't restart between runs, or save the file /tmp/repaired-lba.tmp to non-volatile storage (maybe /var/lib/humaxtv) after each incomplete run and restore it before the next run.

"repaired-lba" is a bit of a euphemism in this filename. It would be more honestly called "erased-and-replaced-lba.tmp".
 
Last edited:
13988 inodes used (0.05%, out of 29860704)
1804 non-contiguous files (12.9%)
20 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 1995/1398/10
76735556 blocks used (64.37%, out of 119209984)
0 bad blocks
62 large files

11634 regular files
894 directories
2 character device files
0 block device files
0 fifos
4 links
1449 symbolic links (1443 fast symbolic links)
0 sockets
------------
13983 files
Memory used: 3224k/0k (1683k/1542k), time: 1947.92/1210.62/87.53
I/O read: 7628MB, write: 1MB, rate: 3.92MB/s
Tue Feb 25 17:02:39 GMT 2020
Removing extra swap space.

Finished
fix-disk: session terminated with exit status 0
 
so, just noticed that my cpu stopped being thrashed to 100% and it now only goes to about 60-70% . not found any pic breakups on new recordings either.
 
mihaid said:
yeah, it seems that fixdisk did its job.
Click to expand...
You only posted a snippet of the fix-disk output which appears to show no problems on the recordings partition; maybe it did something to one of the other partitions. Please could you post the current SMART data for the hard drive.
 
mihaid said:
yeah, it seems that fixdisk did its job.
Click to expand...
So it have been either the SMART disk scan or the filesystem check that made the difference. The current SMART stats could reveal if something relevant changed at the disk level; otherwise it may have been filesystem optimisation of some sort.
 
IDNameFlagsRaw ValueValueWorstThresholdLife LeftNotes
1Raw_Read_Error_RatePOSR--105161467116079006-
3Spin_Up_TimePO----0097097000-
4Start_Stop_Count-O--CK2291207807802073%-
5Reallocated_Sector_CtPO--CK0100100036100%-
7Seek_Error_RatePOSR--1538306569091060030-
9Power_On_Hours-O--CK4350105105100051%-
10Spin_Retry_CountPO--C-0100100097100%-
12Power_Cycle_Count-O--CK1145608908902087%-
184End-to-End_Error-O--CK0100100099-
187Reported_Uncorrect-O--CK14774001001000-
188Command_Timeout-O--CK0100100000-
189High_Fly_Writes-O-RCK0100100000-
190Airflow_Temperature_Cel-O---K52048 (52°C)043 (57°C)045 (55°C)In_the_past
194Temperature_Celsius-O---K52052057000-
195Hardware_ECC_Recovered-O-RC-105161467044033000-
197Current_Pending_Sector-O--C-0100100000-
198Offline_Uncorrectable----C-0100100000-
199UDMA_CRC_Error_Count-OSRCK0200200000-
 
In this serverfault.com answer and a page linked from it, it is claimed that
For Seagate disks (and possibly some old ones from WD too) the Seek_Error_Rate and Raw_Read_Error_Rate are 48 bit numbers, where the most significant 16 bits are an error count, and the low 32 bits are a number of operations.
Click to expand...

If so, the values 105161467 and 1538306569 imply 0 errors in that number of reads and seeks respectively.

As no sectors were reallocated, it appears that either the SMART disk test spruced up one or more flaky sectors as a side-effect, or the filesystem was fixed or optimised in some way, so as to reduce disk access overheads.

In the latter case perhaps the filesystem had acquired some glitch that the automatic "preen" run by the Humax software at startup couldn't correct, leading to a structure that required excessive disk I/O and CPU to traverse. Were there progress messages from the filesystem check ("eg, "Optimizing directories")?

Normally Linux installations are set to force a periodic full filesystem check; however the HD/R setup /etc/mke2fs.conf disables this.
 
mihaid said:
Didn't see anything like that
Click to expand...
Yes, that's what I expected given that the e2fsck option to force directory optimisation isn't used by default in fix-disk, though you can add options when starting it.

Anyhow, now we know that if someone is seeing CPU usage peaking at 100% and experiencing video glitches, fix-disk may be able to SOLVE the problem. Additionally, it could be recommended to run it regularly (depending on how heavily used the box is), without necessarily running the SMART test, to correct any issues the would normally have been fixed by a periodic filesystem check.
 
Except that at least some of us don't have this problem without recourse to fixdisk, so it is not the case that "The CF causes processor overload UNLESS fixdisk used to optimise hard drive again". For the title to be an accurate representation, it would have to read "HDD or file system faults may cause processor overload"... but that's not news.
 
You must log in or register to reply here.
Back
Top