On Fri, Mar 5, 2021 at 1:00 PM Lukas Czerner [off-list ref] wrote:

On Mon, Mar 01, 2021 at 04:42:26PM +0100, Sedat Dilek wrote:

quoted

On Mon, Mar 1, 2021 at 4:34 PM Theodore Ts'o [off-list ref] wrote:

quoted

On Mon, Mar 01, 2021 at 04:12:03PM +0100, Sedat Dilek wrote:

quoted

OK, I see.
So I misunderstood the -o option.

It was clearly documented in the man page:

       -o output_file
              Write the list of bad blocks to the specified file.
              Without this option, badblocks displays the list on
              its standard output.  The format of this file is
              suitable for use by the -l option in e2fsck(8) or
              mke2fs(8).

RTFM.

quoted

I will say that for modern disks, the usefulness of badblocks has
decreased significantly over time.  That's because for modern-sized
disks, it can often take more than 24 hours to do a full read on the
entire disk surface --- and the factory testing done by HDD
manufacturers is far more comprehensive.

In addition, SMART (see the smartctl package) is a much more reliable
and efficient way of judging disk health.

The badblocks program was written over two decades ago, before the
days of SATA, and even IDE disks, when disk controlls and HDD's were
far more primitive.  These days, modern HDD and SSD will do their own
bad block redirection from a built-in bad block sparing pool, and the
usefulness of using badblocks has been significantly decreased.

Thanks for the clarification on badblocks usage and usefulness.

OK, I ran before badblocks:

1. smartctl -a /dev/sdc (shell)
2. gsmartcontrol (GUI)

The results showed me "this disk is healthy".
As you said: Both gave a very quick overview.

- Sedat -

Just note that not even the device firmware can't really know whether the
block is good/bad unless it tries to read/write it. In that way I still
find the badblocks useful because it can "force" the device to notice
that there is something wrong and try to fix it (perhaps by remapping
the bad block to spare one). Of course you could use dd for that, but
there are several reasons why badblocks is still more convenient tool to
do that.

That said you should also check the SMART data _after_ you run the
badblocks to see if it encountered any read errors and/or remapped some
blocks.

Thanks Lukas.

With gsmartcontrol I archived two logs.

The diff says:

cd ~/DISK-HEALTH/gsmartcontrol

git diff ST1000LM024_HN-M101MBB_S2U5J9CCB68827_2020-05-28.txt
ST1000LM024_HN-M101MBB_S2U5J9CCB68827_2021-03-05.txt | egrep -i '
read|remap' | grep -i error
-  1 Raw_Read_Error_Rate     POSR-K   100   100   051    -    0
+  1 Raw_Read_Error_Rate     POSR-K   100   100   051    -    2

There are no "remap" keywords in the gsmartcontrol log-files.

I have attached both log-files.
( Hope there is no sensitive data included. )

- Sedat -

quoted

[1] https://superuser.com/questions/171195/how-to-check-the-health-of-a-hard-drive