Re: [SOLVED, kind of] Re: ext4: debugfs: icheck: Input/output error while calling ext2fs_block_iterate

[Greg Wooledge]

On Sun, Sep 29, 2019 at 03:04:48AM +0200, local10 wrote:
> Sep 28, 2019, 11:24 by bouncingc...@gmail.com:
> 
> > Having read that, I don't see any admission that fsck makes any
> > changes if run without any options as it seems you did. So I
> > wonder what caused the change in the debugfs message.
> >
> 
> man wasn't available in BusyBox so I had to limit myself to the options 
> available through "fsck.ext4 --help". I think I ran it as "fsck.ext4 -cfv 
> /dev/sda", if I remember correctly.

There's always .  It'll redirect
to some variant of the man page in the current stable release, usually.

Re: [SOLVED, kind of] Re: ext4: debugfs: icheck: Input/output error while calling ext2fs_block_iterate

[local10]

Sep 28, 2019, 11:24 by bouncingc...@gmail.com:

> Having read that, I don't see any admission that fsck makes any
> changes if run without any options as it seems you did. So I
> wonder what caused the change in the debugfs message.
>

man wasn't available in BusyBox so I had to limit myself to the options 
available through "fsck.ext4 --help". I think I ran it as "fsck.ext4 -cfv 
/dev/sda", if I remember correctly.


> Personally I think if both smart and fsck are happy then I would
> trust the filesystem. I have done a few repairs like this and never
> had any subsequent problems, but it's worth keeping an eye on
> future smart tests to see if any further errors appear on the drive.
>

The system seems to work fine so far. I'm going to keep an eye on it in the 
near future, just in case.

Thanks to everyone who responded.

Re: [SOLVED, kind of] Re: ext4: debugfs: icheck: Input/output error while calling ext2fs_block_iterate

[Charles Curley]

On Sun, 29 Sep 2019 01:24:00 +1000
David  wrote:

> Having read that, I don't see any admission that fsck makes any
> changes if run without any options as it seems you did. So I
> wonder what caused the change in the debugfs message.

I'll offer a guess. Modern disk drives have a full up controller on
board. That controller has enough smarts that when it detects an error
it can correct, it will transparently correct the error and re-write
the sector.

Sometimes it takes more than one such read and re-write to make the
correction permanent.

In GSmartControl, under the Statistics tab, keep an eye on the number
of reallocated sectors. If you see a non-zero value, your drive is in
trouble. At the prices of modern hard drives, it makes sense to replace
early rather than endure the hassle of restoring from backups, no
matter how well done they are.

Also,if you haven't already done so, set up smartd, which is part of
the smartmontools package.

And think about having a spare drive on hand for the day when that
drive goes south.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: [SOLVED, kind of] Re: ext4: debugfs: icheck: Input/output error while calling ext2fs_block_iterate

[David]

On Sat, 28 Sep 2019 at 22:31, local10  wrote:
> Sep 28, 2019, 02:06 by loca...@tutanota.com:

> > Good advice, thanks. I have a backup drive which is almost a
> > mirror copy of the failing one, so that's why I am not very worried
> > about it. I'm going to try to fix it in a couple of days, so let's see
> > how it goes.

> So I forced fsck to run at reboot, it refused to run in the auto
> mode, dropped me into BusyBox and from there I could run fsck
> manually, pressing  a couple of times telling fsck to ignore
> errors (that was the only option available to me in fsck other than
> quitting it). > After that fsck reported the filesystem clean.

It's great to hear that fsck seems happy with your filesystem.

Just for curiosity, I had a read of 'man e2fsck' and found this:
"""
If  e2fsck  is  run  in  interactive mode (meaning that none of
-y, -n, or -p are specified), the program will ask the user to fix
each problem found in the filesystem.  A response of 'y' will fix the
error; 'n' will leave the error unfixed; and 'a' will fix the problem
and all subsequent problems; pressing Enter will proceed with the
default response, which is printed before the question mark.
Pressing Control-C terminates e2fsck immediately.
"""
and also about the -p option, it does not give much detail in
the man page but a lot more information on -p is here:
https://unix.stackexchange.com/questions/18526/what-does-fsck-p-preen-do-on-ext4

Having read that, I don't see any admission that fsck makes any
changes if run without any options as it seems you did. So I
wonder what caused the change in the debugfs message.

Perhaps the most likely guess is fsck did something to tidy up the
inodes or cause the drive to remap or somehow avoid the bad block.
Maybe someone who knows more will add to this conversation.

Personally I think if both smart and fsck are happy then I would
trust the filesystem. I have done a few repairs like this and never
had any subsequent problems, but it's worth keeping an eye on
future smart tests to see if any further errors appear on the drive.

Re: [SOLVED, kind of] Re: ext4: debugfs: icheck: Input/output error while calling ext2fs_block_iterate

[local10]

Sep 28, 2019, 08:31 by loca...@tutanota.com:

> The end result:
>
Starting with the "The end result:" the email provider I use screwed up the 
email formatting, in the original it was a numbered list which should've looked 
something like this:

The end result:
1. fsck reports the repaired fs as clean
2. The system boots from the repaired root fs and functions normally, no disk 
related errors in the syslog
3. SMART self tests (both short and long) complete successfully, no errors
4. badblocks reports no bad blocks:
...
5. debugfs still looks a bit weird:
...

Hopefully it wasn't too unreadable.

Regards,