badblocks taking really long time. or is it frozen?

I issued the sudo badblocks -nv /dev/sda6 yesterday. I just woke up and it's still like that.

The documentation says that the -n parameter specifies that the test should be non-destructive but takes a little longer time.

Is it working or is it frozen or what? Does anyone know?

3 Answers

You can watch per-process I/O activity with iotop. Install:

sudo apt-get install iotop

Then launch:

sudo iotop

Watch it for 30 sec. Does it show badblocks doing any I/O? If yes, then it is working, if not, it is likely frozen.

Next time you may launch badblocks with the -s parameter:

sudo badblocks -nsv /dev/sda6

this will show progress.

You can see where badblocks is currently positioned in the drive by looking at its fdinfo in proc, i.e:

root@ubuntu:/home/ubuntu# ps ax | grep badblock 3772 tty1 D+ 12:11 badblocks -v /dev/sdb 5478 tty2 S+ 0:00 grep --color=auto badblock
root@ubuntu:/home/ubuntu# ls -l /proc/3772/fd
total 0
lrwx------ 1 root root 64 Mar 3 00:41 0 -> /dev/tty1
lrwx------ 1 root root 64 Mar 3 00:41 1 -> /dev/tty1
lrwx------ 1 root root 64 Mar 3 00:41 2 -> /dev/tty1
lr-x------ 1 root root 64 Mar 3 00:41 3 -> /dev/sdb
root@ubuntu:/home/ubuntu# cat /proc/3772/fdinfo/3
pos: 1707980816384
flags: 0140000
mnt_id: 24
root@ubuntu:/home/ubuntu# lsblk -bd /dev/sdb
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 2000398934016 0 disk 

So, this badblocks run is about 85% done.

@falconer's answer (use iotop) is a nice way to watch its current rate, but fdinfo shows you how much progress the program has made.

Besides iotop, you may also want to look at dmesg:

dmesg -w

In my case, badblocks was stuck at 2.81%, there was no iotop activity and dsmesg showed the followng message on regular intervals:

[ 7371.945131] INFO: task badblocks:19760 blocked for more than 120 seconds.
[ 7371.945134] Tainted: G OE 5.0.0-29-generic #31~18.04.1-Ubuntu
[ 7371.945135] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7371.945136] badblocks D 0 19760 19759 0x00000004
[ 7371.945137] Call Trace:
[ 7371.945140] __schedule+0x2bd/0x850
[ 7371.945141] schedule+0x2c/0x70
[ 7371.945145] io_schedule+0x16/0x40
...

Not sure what the issue is in my case but it may be a bug?