All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
To: Linux RAID Mailing List <linux-raid@vger.kernel.org>
Cc: Håkon <hawken@thehawken.org>
Subject: Feature request: Remove the badblocks list
Date: Tue, 18 Aug 2020 20:00:08 +0200 (CEST)	[thread overview]
Message-ID: <75076966.1748398.1597773608869.JavaMail.zimbra@karlsbakk.net> (raw)

Hi all

It seems the badblocks list was added around 10 years ago[1]. The reason was to keep a track on sectors not readable, which may have made sensee 20 years earlier, but not even in 2010. The first IDE drives came out in the end of the 1980s and were named thus of their 'Integrated Drive Electronics' which was a new thing at the time. Opposed to earlier MFM drives and such, these were "smart" and could handle errors a bit better, even reallocate bad sectors to somewhere else when needed. A lot happened beween 1987 and 2010, but for some reason, this feature slipped through anyway, perhaps becauase Linus was drunk, I don't know. As far as I can understand, this feature works a bit like this

 - If a bad (that is, unreadable) block is found, it is flagged as bad, not to be used ever again, in the md member's superblock
 - If a new disk is added to the array, the block number of the initial bad block is flagged on the new drive, since the whole stripe is rendered useless (erm, didn't we have redundency here?)
 - If replacing the original drive with a new drive, md happily replaces all the data to the new drive and updates the superblock with the same badblock list.

So no attempt is ever done to check or repair that sector. Disks reallocate sectors if they are bad and it's not necessarily a big issue unless there's a lot of such errors. We just say 'this sector or block said *ouch* and is thus dead, and so will his siblings be for ever and ever'. There's a nice article about it here[2].

In practice, if you have data in stripes with badblocks, they may be lost forever and for no reason at all, since drives tend to fix their problems if you issue a write to that sector. ZFS does this nicely - when it finds a bad read, it reconstructs from parity or mirror and writes it again. If it encounters a write error, it tries over. Eventually the drive may fail, but hell, that's why we have redundancy.

As far as I can see, the only solution to remove the badblocks list, is "mdadm ... --assemble --update=no-bbl", from [2], and have md return garbage for those lost sectors, which is fine, since fsck/xfs_repair should fix what's fixable (and still won't be readable anyway). An alternate version written by a friend of mine (Håkon on cc) is present on [3] to remove the list from an offlined array.

As far as I can understand, this list doesn't have any reason to exist, except to annoy sysadmins.

So please remove this useless thing or at least don't enable it by default

[1] https://linux-raid.vger.kernel.narkive.com/R1rvkUiQ/using-the-new-bad-block-log-in-md-for-linux-3-1
[2] https://raid.wiki.kernel.org/index.php/The_Badblocks_controversy
[3] https://git.thehawken.org/hawken/md-badblocktool.git

Vennlig hilsen

roy
-- 
Roy Sigurd Karlsbakk
(+47) 98013356
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
Hið góða skaltu í stein höggva, hið illa í snjó rita.

             reply	other threads:[~2020-08-18 18:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 18:00 Roy Sigurd Karlsbakk [this message]
2020-08-18 19:26 ` Feature request: Remove the badblocks list Wols Lists
2020-08-18 19:34   ` Piergiorgio Sartor
2020-08-18 19:43   ` Phil Turmel
2020-08-18 21:03 ` Håkon Struijk Holmen
2020-08-22  1:42   ` David C. Rankin
2020-09-02 13:36     ` Roy Sigurd Karlsbakk
2020-09-02 14:34       ` Adam Goryachev
2020-09-02 14:50         ` Roy Sigurd Karlsbakk
2020-09-02 15:09           ` Adam Goryachev
2020-09-02 15:25             ` Roy Sigurd Karlsbakk
2020-09-02 16:32               ` Adam Goryachev
2020-09-02 16:50                 ` Roy Sigurd Karlsbakk
2020-09-02 19:45                 ` Håkon Struijk Holmen

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=75076966.1748398.1597773608869.JavaMail.zimbra@karlsbakk.net \
    --to=roy@karlsbakk.net \
    --cc=hawken@thehawken.org \
    --cc=linux-raid@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.