Linux RAID subsystem development
 help / color / mirror / Atom feed
From: 002@tut.by
To: Jeremy Graham <jeremy@doghouse.agency>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: mdadm stuck at 0% reshape after grow
Date: Tue, 05 Dec 2017 18:55:29 +0300	[thread overview]
Message-ID: <1865221512489329@web5g.yandex.ru> (raw)
In-Reply-To: <CAGx2nv6cZ85YCrUQsCBWfojFxOyqW4=+5OaCqU1Gf0UX=T3Gbg@mail.gmail.com>

A well known reason for this behavior are bad blocks in device's BBL, which you happen to have:


> $ mdadm --examine /dev/sd[bcdefg]1

> /dev/sde1:
>           Magic : a92b4efc
>         Version : 1.2
>     Feature Map : 0xc
>      Array UUID : f39f89d2:1bcd3d55:d173d206:d85b8bbc
>            Name : homer2:1
>   Creation Time : Sun Dec 2 12:04:24 2012
>      Raid Level : raid5
>    Raid Devices : 6
>
>  Avail Dev Size : 5860528128 (2794.52 GiB 3000.59 GB)
>      Array Size : 14651317760 (13972.59 GiB 15002.95 GB)
>   Used Dev Size : 5860527104 (2794.52 GiB 3000.59 GB)
>     Data Offset : 2048 sectors
>    Super Offset : 8 sectors
>    Unused Space : before=1960 sectors, after=1024 sectors
>           State : active
>     Device UUID : a33aacb4:00d283ef:5715be52:a0678279
>
>   Reshape pos'n : 491520 (480.00 MiB 503.32 MB)
>   Delta Devices : 1 (5->6)
>
>     Update Time : Tue Dec 5 18:30:50 2017
>   Bad Block Log : 512 entries available at offset 72 sectors - bad
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> blocks present.
^^^^^^^^^^^^^^^^^
>        Checksum : 978e30 - correct
>          Events : 4830578
>
>          Layout : left-symmetric
>      Chunk Size : 512K
>
>    Device Role : Active device 3
>    Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
> /dev/sdf1:
>           Magic : a92b4efc
>         Version : 1.2
>     Feature Map : 0xc
>      Array UUID : f39f89d2:1bcd3d55:d173d206:d85b8bbc
>            Name : homer2:1
>   Creation Time : Sun Dec 2 12:04:24 2012
>      Raid Level : raid5
>    Raid Devices : 6
>
>  Avail Dev Size : 5860528128 (2794.52 GiB 3000.59 GB)
>      Array Size : 14651317760 (13972.59 GiB 15002.95 GB)
>   Used Dev Size : 5860527104 (2794.52 GiB 3000.59 GB)
>     Data Offset : 2048 sectors
>    Super Offset : 8 sectors
>    Unused Space : before=1960 sectors, after=1024 sectors
>           State : active
>     Device UUID : cabeb84a:b5df18c9:cb378062:be0f8998
>
>   Reshape pos'n : 491520 (480.00 MiB 503.32 MB)
>   Delta Devices : 1 (5->6)
>
>     Update Time : Tue Dec 5 18:30:50 2017
>   Bad Block Log : 512 entries available at offset 72 sectors - bad
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> blocks present.
^^^^^^^^^^^^^^^^^
>        Checksum : 9f01ea9c - correct
>          Events : 4830578
>
>          Layout : left-symmetric
>      Chunk Size : 512K
>
>    Device Role : Active device 0
>    Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

This feature generally shouldn't be used, because its implementation is unfinished. Empty BBL's can be removed from every device by giving "--update=no-bbl" option to mdadm on assemble, but before that you must manually regenerate content for each block in BBL's and then manually zero the lists in superblocks.

  parent reply	other threads:[~2017-12-05 15:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05  9:41 mdadm stuck at 0% reshape after grow Jeremy Graham
2017-12-05 10:56 ` Wols Lists
2017-12-05 15:49   ` Nix
2017-12-05 15:55 ` 002 [this message]
2017-12-06  2:51   ` Phil Turmel
2017-12-06  4:33     ` Jeremy Graham
2017-12-06  7:36       ` Jeremy Graham
2017-12-06 13:34         ` Wols Lists
2017-12-06 14:02         ` 002
2017-12-06 10:49       ` Andreas Klauer
2017-12-06 14:15         ` Phil Turmel
2017-12-06 16:03           ` Andreas Klauer
2017-12-06 16:21             ` Phil Turmel
2017-12-06 18:24               ` 002
2017-12-07  8:40                 ` Jeremy Graham
2017-12-06 20:19               ` Edward Kuns
2017-12-07 10:26                 ` Wols Lists
2017-12-07 13:58                 ` Andreas Klauer
2017-12-07 17:06                   ` Wols Lists
2017-12-07 17:40                   ` Andreas Klauer
2017-12-07 20:31                     ` Wols Lists
2017-12-07 23:40                     ` Wols Lists
2017-12-08  1:25                       ` 002
2017-12-09  0:20                       ` Edward Kuns
2017-12-14 12:43                         ` Brad Campbell
2017-12-14 17:32                           ` Edward Kuns

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=1865221512489329@web5g.yandex.ru \
    --to=002@tut.by \
    --cc=jeremy@doghouse.agency \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox