public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: badblocks from e2fsprogs
Date: Fri, 5 Mar 2021 12:59:57 +0100	[thread overview]
Message-ID: <20210305115957.x4gbppxpzxuvn2kd@work> (raw)
In-Reply-To: <CA+icZUUruS8h=CiUwuSsbL9NmCXCvdfV-XFfV=Z=qOpR9b83XA@mail.gmail.com>

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@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 -

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.

-Lukas

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


  reply	other threads:[~2021-03-05 12:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01  9:20 badblocks from e2fsprogs Sedat Dilek
2021-03-01 15:08 ` Theodore Ts'o
2021-03-01 15:12   ` Sedat Dilek
2021-03-01 15:34     ` Theodore Ts'o
2021-03-01 15:42       ` Sedat Dilek
2021-03-05 11:59         ` Lukas Czerner [this message]
2021-03-05 12:21           ` Sedat Dilek
2021-03-05 12:48             ` Lukas Czerner
2021-03-05 12:53               ` Sedat Dilek
2021-03-05 15:55           ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210305115957.x4gbppxpzxuvn2kd@work \
    --to=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox