Linux: reparación de bloques defectuosos en una matriz RAID1 con GPT

Question 1

Todas estas respuestas de "empujar al sector" son, francamente, una locura. Corren el riesgo de dañar el sistema de archivos (posiblemente oculto). Si los datos ya no estuvieran, porque ese disco almacenaba la única copia, sería razonable. Pero hay una copia en perfecto estado en el espejo.

Sólo necesitas que mdraid frote el espejo. Notará el sector defectuoso y lo reescribirá automáticamente.

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

Debe colocar el dispositivo correcto allí (por ejemplo, md0 en lugar de mdX). Esto llevará un tiempo, ya que lo hace con toda la matriz de forma predeterminada. En un kernel suficientemente nuevo, puede escribir números de sector en sync_min/sync_max primero, para limitarlo a solo una parte de la matriz.

Esta es una operación segura. Puedes hacerlo en todos tus dispositivos mdraid. De hecho, tudeberíahazlo en todos tus dispositivos mdraid, regularmente. Es probable que su distribución venga con un cronjob para manejar esto, ¿tal vez necesite hacer algo para habilitarlo?

Script para todos los dispositivos RAID del sistema

Hace un tiempo, escribí este script para "reparar" todos los dispositivos RAID del sistema. Esto fue escrito para versiones anteriores del kernel donde sólo la 'reparación' arreglaría el sector defectuoso; ahora basta con hacer la verificación (la reparación aún funciona bien en los kernels más nuevos, pero también vuelve a copiar/reconstruir la paridad, que no siempre es lo que se desea, especialmente en 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

Si desea hacerlo checken lugar de repair, entonces este primer bloque (no probado) debería 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 respuestas de "empujar al sector" son, francamente, una locura. Corren el riesgo de dañar el sistema de archivos (posiblemente oculto). Si los datos ya no estuvieran, porque ese disco almacenaba la única copia, sería razonable. Pero hay una copia en perfecto estado en el espejo.

Sólo necesitas que mdraid frote el espejo. Notará el sector defectuoso y lo reescribirá automáticamente.

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

Debe colocar el dispositivo correcto allí (por ejemplo, md0 en lugar de mdX). Esto llevará un tiempo, ya que lo hace con toda la matriz de forma predeterminada. En un kernel suficientemente nuevo, puede escribir números de sector en sync_min/sync_max primero, para limitarlo a solo una parte de la matriz.

Esta es una operación segura. Puedes hacerlo en todos tus dispositivos mdraid. De hecho, tudeberíahazlo en todos tus dispositivos mdraid, regularmente. Es probable que su distribución venga con un cronjob para manejar esto, ¿tal vez necesite hacer algo para habilitarlo?

Script para todos los dispositivos RAID del sistema

Hace un tiempo, escribí este script para "reparar" todos los dispositivos RAID del sistema. Esto fue escrito para versiones anteriores del kernel donde sólo la 'reparación' arreglaría el sector defectuoso; ahora basta con hacer la verificación (la reparación aún funciona bien en los kernels más nuevos, pero también vuelve a copiar/reconstruir la paridad, que no siempre es lo que se desea, especialmente en 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

Si desea hacerlo checken lugar de repair, entonces este primer bloque (no probado) debería 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

Acabo de tener prácticamente el mismo problema con una matriz RAID1. El sector defectuoso estaba justo al comienzo de una de las particiones: el sector 16 de /dev/sdb2. Seguí las instrucciones anteriores: después de verificar que el sistema de archivos no estaba utilizando el bloque lógico 2 y teniendo cuidado de obtener dd seek y skip de la manera correcta, puse a cero 1 bloque del sistema de archivos:

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

¿Qué hizo esto? No solucionó el sector malo. Esto, ahora lo sé, se debe a que /dev/md0 no se asigna directamente a /dev/sdb2, ¡debe tener en cuenta el DESPLAZAMIENTO DE DATOS RAID! Más sobre esto a continuación. Lo que sí hizo fue un pequeño pero potencialmente devastador excremento en mi sistema de archivos. Resulta que el bloque lógico 2 de /dev/md0 contenía metadatos útiles del sistema de archivos y estaba bien en ambos discos, hasta que cagué enamboscopias escribiendo a /dev/md0. Afortunadamente, e2fsck -y /dev/md0 solucionó el problema (después de arrojar una cantidad alarmante de resultados) sin pérdida de datos aparente. Lección aprendida: si debugfs icheck dice "bloque no encontrado", no significa necesariamente que no se utilicen los sectores correspondientes.

Volviendo al desplazamiento de datos: use mdadm para encontrar el desplazamiento de esta manera:

# 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)

En este caso, el desplazamiento de datos es de 262144 sectores de 512 bytes. Si agrega desde /dev/md0 y lo compara con datos de la partición sin formato con un desplazamiento de 131072K, encontrará que coinciden. Entonces, en mi caso, el bloque lógico 2 (sectores 16--23) de /dev/sdb2 ni siquiera está en el sistema de archivos; están en el superbloque RAID, sobre el cual puedes leer aquí: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- para la versión 1.2, consta de 256 bytes + 2 bytes por dispositivo en la matriz, todos comenzando con 4096 bytes, por lo que en mi caso, no se utilizó el sector defectuoso. Los sectores correspondientes de /dev/sdc2 (la otra mitad de la matriz RAID1) son cero, así que pensé que sería seguro hacer esto:

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

¡Funcionó!

Answer

Acabo de tener prácticamente el mismo problema con una matriz RAID1. El sector defectuoso estaba justo al comienzo de una de las particiones: el sector 16 de /dev/sdb2. Seguí las instrucciones anteriores: después de verificar que el sistema de archivos no estaba utilizando el bloque lógico 2 y teniendo cuidado de obtener dd seek y skip de la manera correcta, puse a cero 1 bloque del sistema de archivos:

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

¿Qué hizo esto? No solucionó el sector malo. Esto, ahora lo sé, se debe a que /dev/md0 no se asigna directamente a /dev/sdb2, ¡debe tener en cuenta el DESPLAZAMIENTO DE DATOS RAID! Más sobre esto a continuación. Lo que sí hizo fue un pequeño pero potencialmente devastador excremento en mi sistema de archivos. Resulta que el bloque lógico 2 de /dev/md0 contenía metadatos útiles del sistema de archivos y estaba bien en ambos discos, hasta que cagué enamboscopias escribiendo a /dev/md0. Afortunadamente, e2fsck -y /dev/md0 solucionó el problema (después de arrojar una cantidad alarmante de resultados) sin pérdida de datos aparente. Lección aprendida: si debugfs icheck dice "bloque no encontrado", no significa necesariamente que no se utilicen los sectores correspondientes.

Volviendo al desplazamiento de datos: use mdadm para encontrar el desplazamiento de esta manera:

# 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)

En este caso, el desplazamiento de datos es de 262144 sectores de 512 bytes. Si agrega desde /dev/md0 y lo compara con datos de la partición sin formato con un desplazamiento de 131072K, encontrará que coinciden. Entonces, en mi caso, el bloque lógico 2 (sectores 16--23) de /dev/sdb2 ni siquiera está en el sistema de archivos; están en el superbloque RAID, sobre el cual puedes leer aquí: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- para la versión 1.2, consta de 256 bytes + 2 bytes por dispositivo en la matriz, todos comenzando con 4096 bytes, por lo que en mi caso, no se utilizó el sector defectuoso. Los sectores correspondientes de /dev/sdc2 (la otra mitad de la matriz RAID1) son cero, así que pensé que sería seguro hacer esto:

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

¡Funcionó!

Question 3

Si ejecuta Debian, lo más probable es que tenga un trabajo en /etc/cron.d/mdadm. Esto se ejecutará /usr/share/mdadm/checkarray --cron --all --idle --quiet el primer domingo de cada mes. Ejecútelo manualmente cuando obtenga errores de hardware incorregibles para acelerar la reescritura.

Answer

Si ejecuta Debian, lo más probable es que tenga un trabajo en /etc/cron.d/mdadm. Esto se ejecutará /usr/share/mdadm/checkarray --cron --all --idle --quiet el primer domingo de cada mes. Ejecútelo manualmente cuando obtenga errores de hardware incorregibles para acelerar la reescritura.

Question 4

Si tienes un sw-raid1 y escribes datos directamente a uno de los miembros, tendrás un raid corrupto inmediatamente. NO escriba datos en un sdaX o sdbX si son parte de un mdX. Si escribe en mdX, los datos se copiarán en ambas unidades, si lee desde mdX, se leerán los datos de una de las unidades.

Answer

Si tienes un sw-raid1 y escribes datos directamente a uno de los miembros, tendrás un raid corrupto inmediatamente. NO escriba datos en un sdaX o sdbX si son parte de un mdX. Si escribe en mdX, los datos se copiarán en ambas unidades, si lee desde mdX, se leerán los datos de una de las unidades.

Linux: reparación de bloques defectuosos en una matriz RAID1 con GPT

EDITAR 1:

EDITAR 2

EDITAR 3

Respuesta1

Script para todos los dispositivos RAID del sistema

Respuesta2

Respuesta3

Respuesta4

información relacionada