Linux - Reparando blocos defeituosos em um array RAID1 com GPT

Question 1

Todas estas respostas de “cutucar o sector” são, francamente, uma loucura. Eles correm o risco de corrupção (possivelmente oculta) do sistema de arquivos. Se os dados já tivessem desaparecido, porque aquele disco armazenava a única cópia, seria razoável. Mas há uma cópia perfeitamente boa no espelho.

Você só precisa que o mdraid esfregue o espelho. Ele notará o setor defeituoso e o reescreverá automaticamente.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Você precisa colocar o dispositivo correto lá (por exemplo, md0 em vez de mdX). Isso demorará um pouco, pois acontece com todo o array por padrão. Em um kernel novo o suficiente, você pode escrever números de setor primeiro em sync_min/sync_max, para limitá-lo a apenas uma parte da matriz.

Esta é uma operação segura. Você pode fazer isso em todos os seus dispositivos mdraid. Na verdade, vocêdevefaça isso em todos os seus dispositivos mdraid regularmente. Sua distro provavelmente vem com um cronjob para lidar com isso, talvez você precise fazer algo para habilitá-lo?

Script para todos os dispositivos RAID no sistema

Há algum tempo, escrevi este script para "reparar" todos os dispositivos RAID no sistema. Isto foi escrito para versões mais antigas do kernel, onde apenas 'reparar' consertaria o setor defeituoso; agora apenas fazer a verificação é suficiente (o reparo ainda funciona bem em kernels mais novos, mas também copia/reconstrói a paridade, o que nem sempre é o que você deseja, especialmente em unidades flash)

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

Se você quiser fazer checkem vez de repair, então este primeiro bloco (não testado) deve funcionar:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Answer

Todas estas respostas de “cutucar o sector” são, francamente, uma loucura. Eles correm o risco de corrupção (possivelmente oculta) do sistema de arquivos. Se os dados já tivessem desaparecido, porque aquele disco armazenava a única cópia, seria razoável. Mas há uma cópia perfeitamente boa no espelho.

Você só precisa que o mdraid esfregue o espelho. Ele notará o setor defeituoso e o reescreverá automaticamente.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Você precisa colocar o dispositivo correto lá (por exemplo, md0 em vez de mdX). Isso demorará um pouco, pois acontece com todo o array por padrão. Em um kernel novo o suficiente, você pode escrever números de setor primeiro em sync_min/sync_max, para limitá-lo a apenas uma parte da matriz.

Esta é uma operação segura. Você pode fazer isso em todos os seus dispositivos mdraid. Na verdade, vocêdevefaça isso em todos os seus dispositivos mdraid regularmente. Sua distro provavelmente vem com um cronjob para lidar com isso, talvez você precise fazer algo para habilitá-lo?

Script para todos os dispositivos RAID no sistema

Há algum tempo, escrevi este script para "reparar" todos os dispositivos RAID no sistema. Isto foi escrito para versões mais antigas do kernel, onde apenas 'reparar' consertaria o setor defeituoso; agora apenas fazer a verificação é suficiente (o reparo ainda funciona bem em kernels mais novos, mas também copia/reconstrói a paridade, o que nem sempre é o que você deseja, especialmente em unidades flash)

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

Se você quiser fazer checkem vez de repair, então este primeiro bloco (não testado) deve funcionar:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Question 2

Acabei de ter praticamente o mesmo problema com um array RAID1. O setor defeituoso estava logo no início de uma das partições - setor 16 de /dev/sdb2. Segui as instruções acima: depois de verificar se o bloco lógico 2 não estava em uso pelo sistema de arquivos e tomando cuidado para obter dd seek e skip da maneira correta, e zerei 1 bloco do sistema de arquivos:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

O que isso fez? Não corrigiu o setor defeituoso. Agora eu sei que isso ocorre porque /dev/md0 não mapeia diretamente para /dev/sdb2, você deve levar em consideração o RAID DATA OFFSET! Mais sobre isso abaixo. O que ele fez foi uma bosta pequena, mas potencialmente devastadora, no meu sistema de arquivos. Acontece que o bloco lógico 2 de /dev/md0 continha metadados úteis do sistema de arquivos e funcionava bem em ambos os discos, até que eu cagueiamboscópias escrevendo para /dev/md0. Felizmente, e2fsck -y /dev/md0 corrigiu o problema (depois de gerar uma quantidade alarmante de resultados) sem perda aparente de dados. Lição aprendida: se debugfs icheck disser 'bloco não encontrado', isso não significa necessariamente que os setores correspondentes não sejam usados.

De volta ao deslocamento de dados: use mdadm para encontrar o deslocamento assim:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

Neste caso, o deslocamento de dados é de 262.144 setores de 512 bytes. Se você dd de /dev/md0 e compará-lo com os dados da partição bruta com um deslocamento de 131072K, você descobrirá que eles correspondem. Portanto, no meu caso, o bloco lógico 2 (setores 16--23) de /dev/sdb2 nem sequer está no sistema de arquivos; eles estão no superbloco RAID, sobre o qual você pode ler aqui: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- para a versão 1.2, consiste em 256 bytes + 2 bytes por dispositivo no array, todos começando com 4096 bytes, então no meu caso o setor defeituoso não foi utilizado. Os setores correspondentes de /dev/sdc2 (a outra metade do array RAID1) são zero, então imaginei que seria seguro fazer isso:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Funcionou!

Answer

Acabei de ter praticamente o mesmo problema com um array RAID1. O setor defeituoso estava logo no início de uma das partições - setor 16 de /dev/sdb2. Segui as instruções acima: depois de verificar se o bloco lógico 2 não estava em uso pelo sistema de arquivos e tomando cuidado para obter dd seek e skip da maneira correta, e zerei 1 bloco do sistema de arquivos:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

O que isso fez? Não corrigiu o setor defeituoso. Agora eu sei que isso ocorre porque /dev/md0 não mapeia diretamente para /dev/sdb2, você deve levar em consideração o RAID DATA OFFSET! Mais sobre isso abaixo. O que ele fez foi uma bosta pequena, mas potencialmente devastadora, no meu sistema de arquivos. Acontece que o bloco lógico 2 de /dev/md0 continha metadados úteis do sistema de arquivos e funcionava bem em ambos os discos, até que eu cagueiamboscópias escrevendo para /dev/md0. Felizmente, e2fsck -y /dev/md0 corrigiu o problema (depois de gerar uma quantidade alarmante de resultados) sem perda aparente de dados. Lição aprendida: se debugfs icheck disser 'bloco não encontrado', isso não significa necessariamente que os setores correspondentes não sejam usados.

De volta ao deslocamento de dados: use mdadm para encontrar o deslocamento assim:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

Neste caso, o deslocamento de dados é de 262.144 setores de 512 bytes. Se você dd de /dev/md0 e compará-lo com os dados da partição bruta com um deslocamento de 131072K, você descobrirá que eles correspondem. Portanto, no meu caso, o bloco lógico 2 (setores 16--23) de /dev/sdb2 nem sequer está no sistema de arquivos; eles estão no superbloco RAID, sobre o qual você pode ler aqui: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- para a versão 1.2, consiste em 256 bytes + 2 bytes por dispositivo no array, todos começando com 4096 bytes, então no meu caso o setor defeituoso não foi utilizado. Os setores correspondentes de /dev/sdc2 (a outra metade do array RAID1) são zero, então imaginei que seria seguro fazer isso:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Funcionou!

Question 3

Se estiver executando o debian, você provavelmente terá um trabalho em /etc/cron.d/mdadm . Isso acontecerá /usr/share/mdadm/checkarray --cron --all --idle --quiet no primeiro domingo de cada mês. Execute-o manualmente quando ocorrer erros de hardware incorrigíveis para agilizar a reescrita.

Answer

Se estiver executando o debian, você provavelmente terá um trabalho em /etc/cron.d/mdadm . Isso acontecerá /usr/share/mdadm/checkarray --cron --all --idle --quiet no primeiro domingo de cada mês. Execute-o manualmente quando ocorrer erros de hardware incorrigíveis para agilizar a reescrita.

Question 4

Se você tiver um sw-raid1 e gravar dados diretamente em um dos membros, você terá um ataque corrompido imediatamente. NÃO grave dados em um sdaX ou sdbX se eles fizerem parte de um mdX. Se você gravar no mdX, os dados serão copiados para ambas as unidades; se você ler no mdX, os dados serão lidos em uma das unidades.

Answer

Se você tiver um sw-raid1 e gravar dados diretamente em um dos membros, você terá um ataque corrompido imediatamente. NÃO grave dados em um sdaX ou sdbX se eles fizerem parte de um mdX. Se você gravar no mdX, os dados serão copiados para ambas as unidades; se você ler no mdX, os dados serão lidos em uma das unidades.

Linux - Reparando blocos defeituosos em um array RAID1 com GPT

EDITAR 1:

EDITAR 2

EDITAR 3

Responder1

Script para todos os dispositivos RAID no sistema

Responder2

Responder3

Responder4

informação relacionada