Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CA+icZUXzjAniVZMzS5ePNa6HrjWL6ZrpAgzWufy74zHSyN+urQ@mail.gmail.com>
 <YD0DaqIbAf0T2tw2@mit.edu> <CA+icZUXJpEEO4GS1fy9ANXCXJ2BtD_rd1tAtXLun++i0taZwSA@mail.gmail.com>
 <YD0JfjnMtXzGguZ6@mit.edu>
In-Reply-To: <YD0JfjnMtXzGguZ6@mit.edu>
Reply-To: sedat.dilek@gmail.com
From:   Sedat Dilek <sedat.dilek@gmail.com>
Date:   Mon, 1 Mar 2021 16:42:26 +0100
Message-ID: <CA+icZUUruS8h=CiUwuSsbL9NmCXCvdfV-XFfV=Z=qOpR9b83XA@mail.gmail.com>
Subject: Re: badblocks from e2fsprogs
To:     "Theodore Ts'o" <tytso@mit.edu>
Cc:     linux-ext4@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Mar 1, 2021 at 4:34 PM Theodore Ts'o <tytso@mit.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 -

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