Linux-Raid Archives on lore.kernel.org
 help / color / Atom feed
* "--re-add for /dev/sdb1 to /dev/md0 is not possible"
@ 2020-09-15 10:27 Andy Smith
  2020-09-17  8:29 ` Andy Smith
  2020-09-22 10:27 ` Roy Sigurd Karlsbakk
  0 siblings, 2 replies; 4+ messages in thread
From: Andy Smith @ 2020-09-15 10:27 UTC (permalink / raw)
  To: linux-raid

Hi,

In my continuing goal to remove the bad blocks log from any of my
arrays and not have one on any new arrays I create, I wrote this
article:

    https://strugglers.net/~andy/blog/2020/09/13/debian-installer-mdadm-configuration-and-the-bad-blocks-controversy

Shortly afterwards someone on Hacker News¹ said that it is possible
to remove the BBL by failing and re-adding devices, like so:

# mdadm /dev/md127 --fail /dev/sda --remove /dev/sda --re-add /dev/sda --update=no-bbl

I tried that on Ubuntu 18.04:

$ mdadm --version
mdadm - v4.1-rc1 - 2018-03-22
$ sudo mdadm --fail /dev/md0 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1 --update=no-bbl
mdadm: set /dev/sdb1 faulty in /dev/md0
mdadm: hot removed /dev/sdb1 from /dev/md0
mdadm: --re-add for /dev/sdb1 to /dev/md0 is not possible
$ sudo mdadm --add /dev/md0 /dev/sdb1 --update=no-bbl
mdadm: --update in Manage mode only allowed with --re-add.
$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1
$ sudo mdadm --examine-badblocks /dev/sdb1
Bad-blocks list is empty in /dev/sdb1

I tried it on Debian buster:

$ mdadm --version
mdadm - v4.1 - 2018-10-01
$ sudo mdadm --fail /dev/md6 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1 --update=no-bbl
mdadm: set /dev/sdb1 faulty in /dev/md6
mdadm: hot removed /dev/sdb1 from /dev/md6
mdadm: --re-add for /dev/sdb1 to /dev/md6 is not possible

So, is that supposed to work and if so, why doesn't it work for me?

In both cases these are simple two device RAID-1 metadata version
1.2 arrays. Neither has bitmaps.

Thanks,
Andy

¹ https://news.ycombinator.com/item?id=24479235

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "--re-add for /dev/sdb1 to /dev/md0 is not possible"
  2020-09-15 10:27 "--re-add for /dev/sdb1 to /dev/md0 is not possible" Andy Smith
@ 2020-09-17  8:29 ` Andy Smith
  2020-09-22 10:27 ` Roy Sigurd Karlsbakk
  1 sibling, 0 replies; 4+ messages in thread
From: Andy Smith @ 2020-09-17  8:29 UTC (permalink / raw)
  To: linux-raid

On Tue, Sep 15, 2020 at 10:27:36AM +0000, Andy Smith wrote:
> mdadm: --re-add for /dev/sdb1 to /dev/md6 is not possible
> 
> So, is that supposed to work and if so, why doesn't it work for me?
> 
> In both cases these are simple two device RAID-1 metadata version
> 1.2 arrays. Neither has bitmaps.

The lack of bitmaps was why I couldn't use --re-add. I was testing
with small arrays that didn't get a bitmap by default. As mentioned
on the wiki, a bitmap can be added like:

# mdadm --grow --bitmap=internal /dev/mdX

So, as pointed out to me by Jakub Wilk, it is possible to remove the
bad blocks log on a running array by failing and re-adding each
device in turn, as long as you are willing to experience lower / no
redundancy while it rebuilds.

# mdadm --fail /dev/md0 /dev/sdb1 \
        --remove /dev/sdb1 \
        --re-add /dev/sdb1 \
        --update=no-bbl

Cheers,
Andy

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "--re-add for /dev/sdb1 to /dev/md0 is not possible"
  2020-09-15 10:27 "--re-add for /dev/sdb1 to /dev/md0 is not possible" Andy Smith
  2020-09-17  8:29 ` Andy Smith
@ 2020-09-22 10:27 ` Roy Sigurd Karlsbakk
  2020-09-22 23:18   ` antlists
  1 sibling, 1 reply; 4+ messages in thread
From: Roy Sigurd Karlsbakk @ 2020-09-22 10:27 UTC (permalink / raw)
  To: Andy Smith; +Cc: Linux Raid

> In my continuing goal to remove the bad blocks log from any of my
> arrays and not have one on any new arrays I create, I wrote this
> article:
> 
>    https://strugglers.net/~andy/blog/2020/09/13/debian-installer-mdadm-configuration-and-the-bad-blocks-controversy
> 
> Shortly afterwards someone on Hacker News¹ said that it is possible
> to remove the BBL by failing and re-adding devices, like so:
> 
> # mdadm /dev/md127 --fail /dev/sda --remove /dev/sda --re-add /dev/sda
> --update=no-bbl
> 
> I tried that on Ubuntu 18.04:
> 
> $ mdadm --version
> mdadm - v4.1-rc1 - 2018-03-22
> $ sudo mdadm --fail /dev/md0 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1
> --update=no-bbl
> mdadm: set /dev/sdb1 faulty in /dev/md0
> mdadm: hot removed /dev/sdb1 from /dev/md0
> mdadm: --re-add for /dev/sdb1 to /dev/md0 is not possible
> $ sudo mdadm --add /dev/md0 /dev/sdb1 --update=no-bbl
> mdadm: --update in Manage mode only allowed with --re-add.
> $ sudo mdadm --add /dev/md0 /dev/sdb1
> mdadm: added /dev/sdb1
> $ sudo mdadm --examine-badblocks /dev/sdb1
> Bad-blocks list is empty in /dev/sdb1
> 
> I tried it on Debian buster:
> 
> $ mdadm --version
> mdadm - v4.1 - 2018-10-01
> $ sudo mdadm --fail /dev/md6 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1
> --update=no-bbl
> mdadm: set /dev/sdb1 faulty in /dev/md6
> mdadm: hot removed /dev/sdb1 from /dev/md6
> mdadm: --re-add for /dev/sdb1 to /dev/md6 is not possible
> 
> So, is that supposed to work and if so, why doesn't it work for me?
> 
> In both cases these are simple two device RAID-1 metadata version
> 1.2 arrays. Neither has bitmaps.

I've tried this as well, and ran

mddev=/dev/md0
diskdev=/dev/sdm

mdadm --fail $mddev $diskdev
mdadm --remove $mddev $diskdev
mdadm --re-add $mddev $diskdev

All returned ok, but sdm was listed as a slave, thus not active anymore. After this, a new --remove and --re-add didn't work, so it'll take some hours to --add it again (yet another time).

It would be very nice if someone at linux-raid could prioritise this rather obvious bug in the bbl code, where the bbl keeps replicating itself over and over, regardless of any actual failures on the disks. IMHO the whole BBL should be scrapped, as mentioned earlier, since it really has no function. Mapping out bad sectors is for the drive to decide and if it can't handle it, it should be kicked out of the array.

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "--re-add for /dev/sdb1 to /dev/md0 is not possible"
  2020-09-22 10:27 ` Roy Sigurd Karlsbakk
@ 2020-09-22 23:18   ` antlists
  0 siblings, 0 replies; 4+ messages in thread
From: antlists @ 2020-09-22 23:18 UTC (permalink / raw)
  To: Roy Sigurd Karlsbakk, Andy Smith; +Cc: Linux Raid

On 22/09/2020 11:27, Roy Sigurd Karlsbakk wrote:
> It would be very nice if someone at linux-raid could prioritise this rather obvious bug in the bbl code, where the bbl keeps replicating itself over and over, regardless of any actual failures on the disks. IMHO the whole BBL should be scrapped, as mentioned earlier, since it really has no function. Mapping out bad sectors is for the drive to decide and if it can't handle it, it should be kicked out of the array.

Well, I guess if you want a volunteer, you're it! Thanks for steping up 
to the plate!

Cheers,
Wol

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-15 10:27 "--re-add for /dev/sdb1 to /dev/md0 is not possible" Andy Smith
2020-09-17  8:29 ` Andy Smith
2020-09-22 10:27 ` Roy Sigurd Karlsbakk
2020-09-22 23:18   ` antlists

Linux-Raid Archives on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-raid/0 linux-raid/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-raid linux-raid/ https://lore.kernel.org/linux-raid \
		linux-raid@vger.kernel.org
	public-inbox-index linux-raid

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-raid


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git