-
The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm
There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.
SOLVED: The CF causes processor overload UNLESS fixdisk used to optimise hard drive again
- Thread starter mihaid
- Start date
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 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
"repaired-lba" is a bit of a euphemism in this filename. It would be more honestly called "erased-and-replaced-lba.tmp".
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:
Would it be obvious where to find the option y?
MymsMan
Ad detector
see https://wiki.hummy.tv/wiki/Maintenance_Mode_Disk_Check
The option you need most is -y
What does the latest part of the output say?
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
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
MymsMan
Ad detector
Only that it doesn't appear to have found anything to fix and so you still don't know what is causing your pixellation and high Reported_Uncorrect figures
Excellent. Are all your issues resolved now?
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.
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.
| ID | Name | Flags | Raw Value | Value | Worst | Threshold | Life Left | Notes |
|---|---|---|---|---|---|---|---|---|
| 1 | Raw_Read_Error_Rate | POSR-- | 105161467 | 116 | 079 | 006 | - | |
| 3 | Spin_Up_Time | PO---- | 0 | 097 | 097 | 000 | - | |
| 4 | Start_Stop_Count | -O--CK | 22912 | 078 | 078 | 020 | 73% | - |
| 5 | Reallocated_Sector_Ct | PO--CK | 0 | 100 | 100 | 036 | 100% | - |
| 7 | Seek_Error_Rate | POSR-- | 1538306569 | 091 | 060 | 030 | - | |
| 9 | Power_On_Hours | -O--CK | 43501 | 051 | 051 | 000 | 51% | - |
| 10 | Spin_Retry_Count | PO--C- | 0 | 100 | 100 | 097 | 100% | - |
| 12 | Power_Cycle_Count | -O--CK | 11456 | 089 | 089 | 020 | 87% | - |
| 184 | End-to-End_Error | -O--CK | 0 | 100 | 100 | 099 | - | |
| 187 | Reported_Uncorrect | -O--CK | 14774 | 001 | 001 | 000 | - | |
| 188 | Command_Timeout | -O--CK | 0 | 100 | 100 | 000 | - | |
| 189 | High_Fly_Writes | -O-RCK | 0 | 100 | 100 | 000 | - | |
| 190 | Airflow_Temperature_Cel | -O---K | 52 | 048 (52°C) | 043 (57°C) | 045 (55°C) | In_the_past | |
| 194 | Temperature_Celsius | -O---K | 52 | 052 | 057 | 000 | - | |
| 195 | Hardware_ECC_Recovered | -O-RC- | 105161467 | 044 | 033 | 000 | - | |
| 197 | Current_Pending_Sector | -O--C- | 0 | 100 | 100 | 000 | - | |
| 198 | Offline_Uncorrectable | ----C- | 0 | 100 | 100 | 000 | - | |
| 199 | UDMA_CRC_Error_Count | -OSRCK | 0 | 200 | 200 | 000 | - |
In this serverfault.com answer and a page linked from it, it is claimed that
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
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.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.
Black Hole
May contain traces of nut
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.