Fixdisk looping when repairing LBA 0

peterworks

peterworks

Ye Olde Bowler
Hard disk suddenly stopped this afternoon while watching a recording. Had no response with remote or button on front. Switched off, waited 30 seconds and switched on. Humax wanted me to format the drive.
Accessed via telnet and ran fixdisk but it keeps looping back to a LBA 0 error (at 'waiting 28'), supposedly fixes it then starts waiting from 61 again. I cannot access the log but have a screen print (in 2 halves).
Any assistance would be much appreciated - thank you
Fixdisk 1.jpgFixdisk 2.jpg
 
It has now moved on (but in a 'I have not seen before' way as per attached:
Capture16-02-2019-15.52.24.jpg
I will await the final outcome before posting again...
 
Fixdisk finally finished and hard disk okay (all recordings present). Prompted to install WebIf. I restarted and everything is now back including WebIf.
Fixdisk log below (would be interested in the 'ext 3' changed to 'ext 2' then changed back again.
Code: 
----------------------------------------------------------------------
Sat Feb 16 15:35:13 GMT 2019: Fix-disk run starting...
----------------------------------------------------------------------

Checking disk sda (4096 byte sectors)

Running short disk self test
Error at LBA 0
Do you wish to attempt repair of the bad block? [Y/N]: This is an advanced-format disk.
This is an advanced-format disk.
Also checking blocks 0 - 7 (8 blocks)
Also checking blocks 0 - 7 (8 blocks)
    Block 0          - OK
    Block 1          - OK
    Block 2          - OK
    Block 3          - OK
    Block 4          - OK
    Block 5          - OK
    Block 6          - OK
    Block 7          - OK
Running short disk self test
Error at LBA 0
Do you wish to attempt repair of the bad block? [Y/N]: This is an advanced-format disk.
This is an advanced-format disk.
Also checking blocks 0 - 7 (8 blocks)
Also checking blocks 0 - 7 (8 blocks)
    Block 0          - OK
    Block 1          - OK
    Block 2          - OK
    Block 3          - OK
    Block 4          - OK
    Block 5          - OK
    Block 6          - OK
    Block 7          - OK
Running short disk self test
Error at LBA 0
Do you wish to attempt repair of the bad block? [Y/N]: Skipped repair of LBA 0
Checking partition tables...

MBR Status: not present
GPT Status: not present

Partition table is missing/corrupt. If the disk has not been formatted by 
the Humax, recovery by fix-disk may not be successful.

Searching for partitions...

Do you wish to attempt repair of the partition table? [Y/N]: New partition table has been created
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe6c75d8a

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1                8    2104510    2104503     1G 83 Linux
/dev/sda2          2104512 1932539166 1930434655 920.5G 83 Linux
/dev/sda3       1932539168 1953520063   20980896    10G 83 Linux
Using superblock 0 on sda1
Using superblock 0 on sda2
Using superblock 0 on sda3

Sat Feb 16 15:45:36 GMT 2019: Checking partition /dev/sda3...
Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 1: I/O read: 161MB, write: 3MB, rate: 26.99MB/s
Pass 2: Checking directory structure
Pass 2: I/O read: 1MB, write: 1MB, rate: 50.13MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 340k/0k (260k/81k), time:  6.62/ 2.25/ 1.67
Pass 3A: Memory used: 340k/0k (259k/82k), time:  0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 340k/0k (259k/82k), time:  0.01/ 0.00/ 0.00
Pass 3: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 4: Checking reference counts
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Fix? yes

Free blocks count wrong (2510076, counted=2510077).
Fix? yes

Pass 5: I/O read: 1MB, write: 1MB, rate: 0.33MB/s

/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****

          13 inodes used (0.00%, out of 655776)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 1/1/0
      112535 blocks used (4.29%, out of 2622612)
           0 bad blocks
           0 large files

           2 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           4 files
Memory used: 340k/0k (53k/288k), time: 10.93/ 5.34/ 1.72
I/O read: 162MB, write: 3MB, rate: 15.10MB/s
Sat Feb 16 15:45:47 GMT 2019

Sat Feb 16 15:45:47 GMT 2019: Checking partition /dev/sda1...
Pass 1: Checking inodes, blocks, and sizes
Pass 1: I/O read: 17MB, write: 0MB, rate: 19.69MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 140k/0k (72k/69k), time:  0.00/ 0.00/ 0.00
Pass 2: I/O read: 1MB, write: 0MB, rate: 217.49MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 140k/0k (72k/69k), time:  1.11/ 0.28/ 0.49
Pass 3A: Memory used: 140k/0k (72k/69k), time:  0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 140k/0k (71k/70k), time:  0.00/ 0.00/ 0.00
Pass 3: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 4: Checking reference counts
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: I/O read: 1MB, write: 0MB, rate: 3.17MB/s

          15 inodes used (0.02%, out of 65808)
           1 non-contiguous file (6.7%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 2/1/0
       14987 blocks used (5.70%, out of 263062)
           0 bad blocks
           1 large file

           3 regular files
           3 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           6 files
Memory used: 140k/0k (50k/91k), time:  1.57/ 0.66/ 0.50
I/O read: 17MB, write: 1MB, rate: 10.81MB/s
Sat Feb 16 15:45:49 GMT 2019

Creating swap file...

Sat Feb 16 15:46:16 GMT 2019: Checking partition /dev/sda2...
Superblock has an invalid journal (inode 8).
Clear? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data.  Clear? yes


Force rewrite? yes


Pass 1: I/O read: 333MB, write: 1MB, rate: 0.43MB/s
Pass 2: Checking directory structure
Pass 2: I/O read: 5MB, write: 0MB, rate: 1.66MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 1192k/0k (1057k/136k), time: 785.89/270.36/10.85
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 1192k/0k (1051k/142k), time:  0.05/ 0.04/ 0.01
Pass 3: I/O read: 1MB, write: 0MB, rate: 20.66MB/s
Pass 4: Checking reference counts
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Fix? yes

Fix? yes

Free blocks count wrong for group #3682 (32715, counted=32758).
Fix? yes

Free blocks count wrong for group #4465 (4, counted=1028).
Fix? yes

Free blocks count wrong (215836962, counted=215870787).
Fix? yes

Pass 5: I/O read: 58MB, write: 0MB, rate: 0.75MB/s
Recreate journal? yes

Creating journal (32768 blocks):  Done.

*** journal has been re-created - filesystem is now ext3 again ***

/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****

       10012 inodes used (1.06%, out of 942720)
         117 non-contiguous files (1.2%)
          11 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 376/91/3
    25466345 blocks used (10.55%, out of 241304331)
           0 bad blocks
           8 large files

        8141 regular files
         440 directories
           0 character device files
           0 block device files
           0 fifos
           2 links
        1422 symbolic links (1422 fast symbolic links)
           0 sockets
------------
       10005 files
Memory used: 1468k/0k (689k/780k), time: 899.36/288.91/16.43
I/O read: 396MB, write: 162MB, rate: 0.62MB/s
Sat Feb 16 16:01:16 GMT 2019
Removing extra swap space.

----------------------------------------------------------------------
Sat Feb 16 16:01:18 GMT 2019: Fix-disk run ended.
----------------------------------------------------------------------

This is how the Disk Diagnostics - Attributes look:
Capture16-02-2019-16.10.56.jpg

I assume I should run another Fixdisk to sort out the 'pending sector' and 'uncorrectable' lines that are highlighted but can someone please confirm that that should be my next move please.
 
LBA0 is critical on a disk (it stores partitioning information) and cannot be swapped out. Any disk showing LBA0 errors must be considered suspect.
 
Your disk doesn't seem to be very old. Is it still under warranty? It definitely is near the end of its life.
And yet more evidence about number of start/stops vs. number of power-on-hours.
 
Black Hole said:
LBA0 is critical on a disk (it stores partitioning information) and cannot be swapped out.
Click to expand...
Why not? Clearly it has been, otherwise the previous partition table that got destroyed wouldn't have been able to be recreated.
 
I purchased the disk in December 2017 so not that old. I have contacted the seller (on Amazon) but do not hold out much hope.
 
prpr said:
Why not? Clearly it has been, otherwise the previous partition table that got destroyed wouldn't have been able to be recreated.
Click to expand...
Well, I'm sure you will correct me if I'm wrong, but doesn't the hardware use LBA0 at the lowest level to know how to interpret the rest of the disk? The data has to be on LBA0, even if there is a backup of it, and if LBA0 gets a hard fault (rather than a soft one) the disk is stuffed.
 
Black Hole said:
Well, I'm sure you will correct me if I'm wrong, but doesn't the hardware use LBA0 at the lowest level to know how to interpret the rest of the disk? The data has to be on LBA0, even if there is a backup of it, and if LBA0 gets a hard fault (rather than a soft one) the disk is stuffed.
Click to expand...
If it gets a hard fault on a particular sector then a spare sector will be swapped in (until the supply of spare sectors is used up).
 
Yes but is that true of LBA 0?
I suppose by definition, it could be anywhere, but how does the HDD controller find it?
 
Controller technology has moved on since the bad old days of disks where everything was hard mapped, and bad sectors were the responsibility of the filesystem to deal with (avoid). Then if LBA 0 went bad, you were stuffed, as there was no way to write/read the partition table. These days it just gets re-mapped, like any other sector on the disk. There is nothing special about LBA 0. It's just another pigeon-hole, like all the rest.
 
Trev said:
Yes but is that true of LBA 0?
I suppose by definition, it could be anywhere, but how does the HDD controller find it?
Click to expand...
The hard drive controller doesn't know anything about the file system sitting on the disk; it just knows that a particular sector is in trouble and maps in a fresh sector.
 
So why do we get so much trouble with LBA0 and fixdisk? Do we need some way to mark it bad so the controller remaps it? The remapping mentioned above strikes me as the sort of thing done at production test rather than live.
 
Black Hole said:
So why do we get so much trouble with LBA0 and fixdisk?
Click to expand...
Because LBA0 is where the partition table is stored and if that is unreadable fixdisk doesn't know how the file systems are arranged. I agree it is a bit odd that it gives a lot of trouble because I wouldn't expect it to be written to very often.
Do we need some way to mark it bad so the controller remaps it?
Click to expand...
Good question but I don't know the answer.
The remapping mentioned above strikes me as the sort of thing done at production test rather than live.
Click to expand...
It is done at both production test and live in service but in slightly different ways: this link gives an explanation that matches my understanding: https://www.mjm.co.uk/articles/bad-sector-remapping.html
 
You must log in or register to reply here.
Back
Top