• 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.

Fix-Disk loop

3

3rddawn

New Member
Hi
I had a warning about hard disk errors (197,198) so did maintenance mode, 1 - check and repair disk.
The first time I did it, after having to say No to attempting to repair a bad block, it finished doing all its tests.

Following the fix-disk notes, because it had errors 197, 198, I reran it with the test/repair option.
Near the beginning there was this bit:-
Running short disk self test
Error at LBA 577252608
Do you wish to attempt repair of the bad block? [Y/N]: y
/dev/sda:
re-writing sector 577252608: succeeded

which looped until I chose No instead of Yes, then it moved on.

Now it's in a continuous loop, has been for about 2 hours.
Here's what keeps repeating ...

Checking to see if this block is in use...
debugfs 1.42.10 (18-May-2014)
Block 71893511 is marked as in use
Searching for inode...
debugfs 1.42.10 (18-May-2014)
Inode: 15409174
The following file contains a corrupt block and can not be fully recovered.
You may wish to delete it or recover from backup.
debugfs 1.42.10 (18-May-2014)
ncheck: Can't read next inode while doing inode scan
Inode Pathname
15409174 /mnt/hd2/mod/tmp/redring.log
Dev: /dev/sda LBA: 577252608
LBA: 577252608 is on partition /dev/sda2, start: 2104515, bad sector offset: 575
148093
dumpe2fs 1.42.10 (18-May-2014)
Using superblock 0
Block size: 4096
LBA 577252608 maps to file system block 71893511 on /dev/sda2

[Here's the restart of the loop] Checking to see if this block is in use...
debugfs 1.42.10 (18-May-2014)

Please can anyone advise if this is really in a loop as none of the numbers change - they're identical, or if' this is "normal"?
If it's stuck in a loop, is there a safe way to force fix-disk to quit without just switching the Hummy off with the switch?

Thanks
3rddawn
 
Update: Eventually found Ctrl ] will break out of it.
Deleted the file it was referring to (redring.log) and repeated from reboot and re-entering maintenance mode and a "proper" check/fix (i.e. selecting 1 from the menu) is in progress. It got past the loop blockage because the block was not in use this time :)

Might it be worth adding to the wiki page about maintenance mode that Ctrl ] can be used to abort during a test (if that is safe to do!)?

[Later]
Test completed on it's own.
I still have the same problem showing on the disk diagnostic, but at least there's no delay when pressing play or pause (which were the symptoms I was having that prompted me to look and found the disk errors).
 
Last edited:
Hi @Ezra Pound

Sorry about resurrecting this thread.... please could I ask you also to add a note about the different messages you might see whilst doing a fix disk and what you might do. I suspect there may be some caveats but if a general gist or directions could be provided that would be great.

I've given some examples below

Thanks

Rodp

Eg. 'Can't read next inode while doing inode scan'. In my case I'm running fixdisk with the options -l -y. My HDD seems to be a bad way as it was finding many more bad sectors / blocks compared to the normal fixdisk process (ie not the -l long method, just the -y option). It then moved onto running debugfs as part of the whole process and now seems to be saying 'Can't read next inode while doing inode scan'. Currently it's talking about dumpe2fs which I am assuming is a temporary swap file for the e2fsck program.

eg
Code: 
Dev: /dev/sda LBA: 1285267736                                                                                                                                                                                 
LBA: 1285267736 is on partition /dev/sda2, start: 2104515, bad sector offset: 1283163221                                                                                                                     
dumpe2fs 1.42.13 (17-May-2015)                                                                                                                                                                               
Using superblock 0                                                                                                                                                                                           
Block size: 4096                                                                                                                                                                                             
LBA 1285267736 maps to file system block 160395402 on /dev/sda2                                                                                                                                               
                                                                                                                                                                                                              
Checking to see if this block is in use...                                                                                                                                                                   
debugfs 1.42.13 (17-May-2015)                                                                                                                                                                                 
Block 160395402 is marked as in use                                                                                                                                                                           
                                                                                                                                                                                                              
Searching for inode...                                                                                                                                                                                       
debugfs 1.42.13 (17-May-2015)                                                                                                                                                                                 
: Can't read next inode while doing inode scan

another eg.
Code: 
The following file contains a corrupt block and can not be fully recovered.                                                                                                                                   
Inode   Pathname                                                                                                                                                                                             
LBA: 467937880 is on partition /dev/sda2, start: 2104515, bad sector offset: 465833365                                                                                                                       
LBA 467937880 maps to file system block 58229170 on /dev/sda2                                                                                                                                                 
Block 58229170 is marked as in use

Could you explain why / what Inode Pathname means? Is this ok or should Pathname be replaced with something? This message appears a number of times but then eventually went onto the former message.

The LBA and block numbers are different each message so I guess it's working as expected but if there is something that these messages mean and like the previous messages above in this thread, the OP moved / deleted a .log file, I might consider this.


EDIT..... It's taking a very long time to do the debugfs part - each block / LBA value takes about 5 minutes and so I'm wondering what the purpose of this step is for. I'm thinking perhaps I should cancel it but I don't know what important fixing stage I'm going to miss if I do.?
 
Last edited:
The Smartmontools Bad blocks How-to Wiki link that I posted yesterday explains what's going on.
rodp said:
...
'Can't read next inode while doing inode scan'
...
Click to expand...
debugfs ncheck is traversing the filesystem structure (one 'inode' per file/directory) but the inode of interest can't be read (probably one of your disk's bad blocks). Whatever blocks of the file or directory that it represented will end up as an anonymous file or directory (respectively) in the lost+found directory of the filesystem's root directory.
... dumpe2fs ...
Click to expand...
The tool that extracts ext[234]fs filesystem settings.
Code: 
The following file contains a corrupt block and can not be fully recovered.                                                                                                                                   
Inode   Pathname                                                                                                                                                                                             
LBA: 467937880 is on partition /dev/sda2, start: 2104515, bad sector offset: 465833365                                                                                                                       
LBA 467937880 maps to file system block 58229170 on /dev/sda2                                                                                                                                                 
Block 58229170 is marked as in use
Click to expand...
This is supposed to be telling you which file/directory contains the "corrupt block" 58229170, using a debugfs command. But apparently the command output isn't in the expected format, perhaps because, as it says, an inode is unreadable, and the subsequent command that should extract the file name doesn't do so. I'll have to check the CF3.13 version, which is newer than the repo 0.5 version I have here; in 0.5 it does
Code: 
debugfs -b $bs -s $sb -R "ncheck $inode" $bad_part
where bs: block size; sb: super-block address; inode: inode number; bad_part: /dev/sda2.
The LBA and block numbers are different each message so I guess it's working as expected ...
Click to expand...
It would be if it was actually logging the affected files properly. However it will still go on and should (eventually) give you back a working filesystem, even if it doesn't tell you which files were clobbered.
 
Oh so Dumpe2fs is not a swap file, it's just a program. It's been on the same file for 12 hours now - is this debugfs essential? Will this information it's churning out (searching for inodes etc be used further in the process).
 
dumpe2fs gets some initial filesystem settings which are passed to debugfs to locate how, if at all, each bad block is used by the filesystem. This is supposed to help you by listing which files might have been affected by a bad block, so that you can check the validity of the file afterwards, instead of (eg) playing all your recovered recordings to see if any are unwatchable. Conceivably if a disk is very sick this procedure could fail, or, as you observe, might just be very time-consuming (block n is bad, what file is it? that one; oh, block n+1 is bad too, what file is it? the same one; ...).

The -B option to fix-disk turns off this part of the process.
 
/df said:
This is supposed to help you by listing which files might have been affected by a bad block, so that you can check the validity of the file afterwards
Click to expand...
But does this information get put anywhere reasonably accessible, without wading through pages of irrelevant detail?
 
In the log files, it seems to have removed this info - it's only by chance I took a copy of the terminal window that I saw this info. Is this a bug? 1600188529659.png
 
rodp said:
In the log files, it seems to have removed this info - it's only by chance I took a copy of the terminal window that I saw this info. Is this a bug?
Click to expand...
It doesn't look like a bug to me. Just an attempt to minimise the size of the log file.
 
You must log in or register to reply here.
Back
Top