Bug 197315

Summary: ext4 filesystem does not use its badblock list fully
Product: File System Reporter: dima (mihailov-d-v)
Component: ext4Assignee: fs_ext4 (fs_ext4)
Status: NEW ---    
Severity: normal    
Priority: P1    
Hardware: x86-64   
OS: Linux   
URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1723415
Kernel Version: 4.14.0-041400rc4.201710130854 Subsystem:
Regression: No Bisected commit-id:
Attachments: tune2fs -l
dumpe2fs
related dmesg outputs

Description dima 2017-10-19 03:16:10 UTC
Always, when I have /dev/sdb2 mounted, I get an errors in the system log, such as in the file dmesg.txt (attached)(there are i/o errors and something).

Thus I ran fsck:
{
root@user:~# fsck.ext4 -fck /dev/sdb2
e2fsck 1.43.5 (04-Aug-2017)
Checking for bad blocks (read-only test): 0.24% done, 0:25done
/dev/sdb2: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Programming error? block #230376 claimed for no reason in process_bad_block.
Programming error? block #230385 claimed for no reason in process_bad_block.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdb2: ***** FILE SYSTEM WAS MODIFIED *****
}

But the errors did not disappear and I ran "badblocks -so ./bads-sdb2.txt -b 4096 /dev/sdb2"
Then I tried "fsck.ext4 -l ./bads-sdb2.txt /dev/sdb2" and it showed, among other typical things, this:
{
Programming error? block #230376 claimed for no reason in process_bad_block.
Programming error? block #230385 claimed for no reason in process_bad_block.
}

Then I ran "dump2fs -b /dev/sdb2" and found that every block from bads-sdb2.txt is already included in there, but the errors keep appear.

And while I was searching for a solution, I found this:
https://sourceforge.net/p/e2fsprogs/bugs/187/

I think this situation can be found on Ubuntu 16.04 too.
Thank you.

1) Ubuntu Artful Aardvark (development branch) 17.10
2) 4.13.0.15.16
...
I've tried to calculate somehow what block is on sector 50868652 and I got 6291509. Badblocks program successfully recognize this block as bad. And "dumpe2fs -b" shows it. But this block is touched again and again. And I think that means that messages "Programming error? block #?????? claimed for no reason in process_bad_block" are irrelevant to this issue.
...
I used 4.14.0-041400rc4.201710130854 kernel for testing and the bug exists on it too.
Comment 1 dima 2017-10-19 03:20:54 UTC
Created attachment 260279 [details]
tune2fs -l
Comment 2 dima 2017-10-19 03:22:49 UTC
Created attachment 260281 [details]
dumpe2fs
Comment 3 dima 2017-10-19 03:27:01 UTC
Created attachment 260283 [details]
related dmesg outputs

This output was received before the name of the disk was automatically changed after reboot