ZFS: ¿Cómo restaura la cantidad correcta de copias después de perder una unidad?


12

Con zfs, si tiene copies=2y luego pierde una unidad que contiene algunas de esas copias, ¿cómo le dice al sistema que debe hacer una nueva copia de los bloques de datos para los archivos afectados? ¿O zfs simplemente comienza a agregar bloques de datos para las copias adicionales tan pronto como se entera de bloques de datos incorrectos?

¿Scrub hará esto?

(v0.6.0.56-rc8, ZFS pool versión 28, sistema de archivos ZFS versión 5, Ubuntu 11.10)

Respuestas:


10

"copias = 2" (o 3) está más diseñado para usarse con grupos sin redundancia (disco único o bandas). El objetivo es poder recuperar daños menores en el disco, no una falla completa del dispositivo. En el último caso, el grupo no se puede montar, por lo que no se puede restaurar el mismo bloque.

Si tiene redundancia (duplicación / raidz / raidz2 / raidz3), los bloques ídem no son diferentes a los demás y la limpieza / recuperación los recreará.


Esto entra directamente en conflicto con lo que dice @Redmumba, y Redmumba proporciona enlaces al código. ¿Puedes citar algunas fuentes de lo que estás diciendo? En particular, me encantaría ver buenas citas de por qué crees que copias = N no va a hacer frente a la falla total del dispositivo, eso no coincide con nada de lo que he leído.
James Moore

1
@ James Moore Después de un fallo completo del dispositivo, no se escribirán bloques ídem en ese disco. No hay redundancia a nivel de grupo, por lo que no hay forma de reemplazar el disco defectuoso por uno nuevo. El único método para recuperar adecuadamente esa situación sería hacer una copia de seguridad completa del grupo, volver a crearla con dispositivos en buen estado y restaurarla desde la copia de seguridad mientras se asegura de que no se produzca un reinicio involuntario antes de que se realice la primera copia de seguridad. De lo contrario, el grupo podría no ser importable y perder sus datos. Esto es una carga considerable en comparación con los grupos redundantes donde la recuperación de un disco defectuoso se realiza en línea y sobrevive a los reinicios.
jlliagre

1
Aquí hay una referencia: docs.oracle.com/cd/E19082-01/817-2271/gbbvf/… For a device to be replaced, the pool must be in the ONLINE state. The device must be part of a redundant configuration, or it must be healthy (in the ONLINE state). Supongo que copias = 2 o 3 no se considera una configuración redundante.
jlliagre

1
Sin embargo, una cosa a tener en cuenta es que si originalmente lo había hecho copies=1y lo ha mejorado copies=2, es probable que luego desee volver a cargar / resubrir, lo que creará estas instancias. Pero @jilliagre es correcto: los bloques ídem no constituyen una configuración redundante. NO hay garantía de que los bloques se establezcan en otro dispositivo, incluso si tiene varios dispositivos en un grupo.
Andrew M.

1
la función "copias = N donde N> 1" no pretende agregar redundancia. está destinado a resolver la corrupción de datos. todo lo escrito en zfs tiene una suma de comprobación o hash. cuando se vuelve a leer, se verifica la suma de comprobación / hash. si N = 1, entonces una falla de verificación de suma de comprobación / hash resulta en un error de regreso a la aplicación. si N> 1, entonces se puede consultar una de las otras copias y utilizarla para reparar todas las demás copias.
longneck

9

Encontré esta pregunta realmente intrigante, y después de pasar una hora revisando la documentación, me sumergí en el código. Esto es lo que encontré.

Primero, algo de terminología. Los bloques ídem (que son lo que son estas copias, a diferencia de los espejos) se crean automáticamente en una escritura, pero pueden o no estar en el mismo dispositivo virtual (vdev) que la copia original. Por otro lado, los bloques reflejados siempre se reflejan en otro dispositivo virtual.

Sin embargo, el código se refiere a ambos tipos de bloques como hijos. Verá aquí que los bloques ídem son solo hijos con io_vd == NULL(esto está en la función de escritura). Para un bloque reflejado, io_vdse establecería en el dispositivo virtual correspondiente (su segundo disco, por ejemplo).

Con eso en mente, cuando llega a la parte de lectura , trata a todos los niños (ya sean espejo o bloques idénticos) como potencialmente inseguros si no contiene el esperadogood_copies , y los reescribe según sea necesario . Por lo tanto, parece que la respuesta a su pregunta es: sí, los reescribirá cuando tenga al menos una buena copia, y cualquiera de los siguientes:

  • Errores inesperados al intentar leer los datos,
  • Estás resistiendo, o
  • Estás fregando

¡Uf! Tal vez alguien pueda señalar fallas, pero disfruté aprendiendo sobre ZFS a través de este pequeño ejercicio, ¡y espero que esto ayude!


1
El problema está en la respuesta de @ jlliagre: el grupo está muerto si pierde algún dispositivo. El hecho de que el grupo aún tenga suficientes bloques ídem no parece importar. ¿Alguna forma de evitar eso?
James Moore

44
@JamesMoore puede forzar la matriz en línea en un estado degradado si tiene el primer 1 MB del dispositivo que falló. Presumiblemente solo necesita los metadatos del dispositivo fallido. He probado esto con un zpool de estilo jbod y funciona: recuperando etiquetas rotas de raidz . Hice un md5sum antes y después de romper el zpool, y solo el sistema de archivos copias = 1 se rompió después de la importación. Los sistemas de archivos copias = 2 y copias = 3 coincidieron perfectamente.
Jodie C

2

@jlliagre y otros que parecen pensar que el zpool completo muere si uno de los discos (vdevs) muere pero el grupo no es redundante (espejo / raidz). Esto no es verdad; un multidisco piscina será siempre sobrevivir a un fallo de disco único completa, incluso si no es un espejo o raidz.

Los metadatos de ZFS siempre se copian al menos 2 veces, por lo que la falla total de un disco completo (o cualquier parte del mismo) no eliminará el sistema de archivos. Además, muchos archivos, especialmente los más pequeños, no se distribuirán en todos los discos y, por lo tanto, no necesariamente se verán afectados por la falla del disco. El OP pregunta sobre el caso de un grupo de discos múltiples que utiliza bloques ídem (copias de datos del usuario> 1). Aquí, una sola falla completa del disco nunca debería dar como resultado ninguna pérdida de datos.ZFS siempre intentará colocar bloques ídem lejos del bloque original, y para grupos con múltiples vdevs, esto siempre significa en otro vdev (una excepción podría ser donde un vdev es> 50% del grupo, lo cual sería muy inusual) . Los metadatos del sistema de archivos también siempre se copian +1 o +2 veces más que el nivel ídem , por lo que siempre sobrevivirá a la falla del disco. Además, si tiene un grupo de más de tres discos, debería poder perder hasta la mitad de ellos sin pérdida de datos; ZFS almacena los bloques ídem en el siguiente disco, por lo que siempre que nunca pierda dos discos adyacentes, nunca tendrá pérdida de datos. (falla de tres discos adyacentes para ídem = 2).

Cuando hay suficientes copias de datos para acceder a un archivo (ya sea que esas copias sean de bloques ídem, espejo o raidz), todas las copias faltantes de datos se reparan cuando se accede al archivo. Este es el propósito del exfoliante; lea todos los datos y corrija los que sean malos haciendo uso de copias redundantes. Por lo tanto, para responder directamente a la pregunta de OP, solo necesita hacer un fregado después de reemplazar la unidad fallida, y todas las copias se restaurarán.

Como siempre, puede experimentar fácilmente con los conceptos creando grupos cuyos vdevs para el almacén de respaldo son simplemente archivos dispersos comunes. Al eliminar o corromper los archivos vdev, puede simular cualquier tipo de falla y puede verificar la integridad del grupo, los sistemas de archivos y los datos en el camino.

EDITAR: después de experimentar, parece que zfs fallará en el grupo si falla un disco en un grupo no redundante multidisco con copias> = 2. La corrupción de datos paritales en uno o más discos debe poder sobrevivir y debe ser reparada por un exfoliante.


Lo aterrador de este tipo de experimentos es que son geniales para decirme que una configuración fallará de inmediato o al menos rápidamente. No son tan buenos para decirme que una configuración fallará ocasionalmente. En cualquier caso, no está claro cómo recuperar un grupo que tiene un error; Intenté configurar un grupo como este con tres archivos dispersos y eliminar uno de los archivos dispersos parece ser fatal para todo el grupo. zpool replace no reemplazará el archivo fallido, zpool scrub se detiene al 5% (y estos son grupos muy pequeños), y la página de error en illumos.org/msg/ZFS-8000-5E no es optimista.
James Moore

Tuve un resultado similar a mis experiencias, hecho solo después de mi respuesta. Normalmente solo uso raidz, y respondía en base a información de lo que creía que eran fuentes creíbles (blogs de Oracle). Ya no creo que un grupo de tipos JBOD multidisco, con copias> 1 pueda sobrevivir a un fallo de disco.
Aaron B
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.