Message-ID: <CA+icZUWZ8-005hOOaapW=0EnySD7jcL6RaFsiMXV6EPfvmG1Vg@mail.gmail.com>
Date:   Fri, 5 Mar 2021 13:21:51 +0100
From:   Sedat Dilek <sedat.dilek@...il.com>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     "Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: badblocks from e2fsprogs

On Fri, Mar 5, 2021 at 1:00 PM Lukas Czerner <lczerner@...hat.com> wrote:
>
> On Mon, Mar 01, 2021 at 04:42:26PM +0100, Sedat Dilek wrote:
> > On Mon, Mar 1, 2021 at 4:34 PM Theodore Ts'o <tytso@....edu> wrote:
> > >
> > > On Mon, Mar 01, 2021 at 04:12:03PM +0100, Sedat Dilek wrote:
> > > >
> > > > 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.
> >
> > > 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 -

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

View attachment "ST1000LM024_HN-M101MBB_S2U5J9CCB68827_2020-05-28.txt" of type "text/plain" (12900 bytes)

View attachment "ST1000LM024_HN-M101MBB_S2U5J9CCB68827_2021-03-05.txt" of type "text/plain" (12579 bytes)

Powered by blists - more mailing lists