Capítulo 11 Recuperación de agrupaciones y solución de problemas de Oracle Solaris ZFS
En este capítulo se explica la forma de identificar y solucionar errores de ZFS. También se proporciona información para la prevención de errores.
Este capítulo se divide en las secciones siguientes:
Identificación de errores de ZFS
Como combinación de sistema de archivos y administrador de volúmenes, ZFS puede presentar una amplia modalidad de errores. Este capítulo comienza con una breve introducción de los diversos errores y posteriormente explica el modo de identificarlos en un sistema que está en funcionamiento. Al final del capítulo, se proporcionan instrucciones para solucionar los problemas. ZFS puede tener tres tipos básicos de errores:
-
Dispositivos que faltan en una agrupación de almacenamiento de ZFS
-
Dispositivos dañados de una agrupación de almacenamiento de ZFS
En una misma agrupación se pueden dar los tres errores, con lo cual un procedimiento completo de reparación implica detectar y corregir un error, luego ocuparse del siguiente error y así sucesivamente.
Dispositivos que faltan en una agrupación de almacenamiento de ZFS
Si un dispositivo ha desaparecido totalmente del sistema, ZFS detecta que dicho dispositivo no se puede abrir y le asigna el estado REMOVED. Según el nivel de repetición de datos que tenga la agrupación, la desaparición no tiene porqué significar que toda la agrupación deje de estar disponible. Si se elimina un disco de un dispositivo RAID-Z o reflejado, la agrupación sigue estando disponible. Una agrupación podría tener el estado FAULTED; esto significa que no será posible acceder a sus datos hasta que no se vuelva a colocar el dispositivo, en las condiciones detalladas a continuación:
-
Si se eliminan todos los componentes de un reflejo
-
Si se elimina más de un dispositivo en un RAID-Z (raidz1)
-
Si se elimina un dispositivo de nivel superior en una configuración de un solo disco
Dispositivos dañados de una agrupación de almacenamiento de ZFS
El término "dañado" se aplica a una amplia diversidad de errores. Entre otros, están los errores siguientes:
-
Errores transitorios de E/S debido a discos o controladores incorrectos
-
Datos en disco dañados por rayos cósmicos
-
Errores de controladores debidos a datos que se transfieren o reciben de ubicaciones incorrectas
-
Anulación involuntaria de partes del dispositivo físico por parte de un usuario
En determinados casos, estos errores son transitorios, por ejemplo errores aleatorios de E/S mientras el controlador tiene problemas. En otros, las consecuencias son permanentes, por ejemplo la corrupción del disco. Aun así, el hecho de que los daños sean permanentes no implica necesariamente que el error se repita más adelante. Por ejemplo, si un administrador sobrescribe involuntariamente parte de un disco, no ha habido ningún error de hardware y no hace falta reemplazar el dispositivo. No resulta nada fácil identificar con exactitud lo que ha sucedido en un dispositivo. Ello se aborda en mayor profundidad más adelante en otra sección.
Datos dañados de ZFS
El deterioro de datos tiene lugar cuando uno o varios errores de dispositivos (dañados o que faltan) afectan a un dispositivo virtual de nivel superior. Por ejemplo, la mitad de un reflejo puede sufrir innumerables errores sin causar la más mínima corrupción de datos. Si se detecta un error en la misma ubicación de la otra parte del reflejo, habrá datos dañados.
Los datos quedan permanentemente dañados y deben tratarse de forma especial durante la reparación. Aunque se reparen o reemplacen los dispositivos subyacentes, los datos originales se pierden irremisiblemente. En estas circunstancias, casi siempre se requiere la restauración de datos a partir de copias de seguridad. Los errores de datos se registran conforme se detectan. Como se explica en la sección siguiente, pueden controlarse mediante limpiezas de agrupación rutinarias. Si se quita un bloque dañado, el siguiente pase de limpieza reconoce que el deterioro ya no está presente y suprime del sistema cualquier indicio de error.
Comprobación de integridad de sistema de archivos ZFS
En ZFS no hay una utilidad fsck equivalente. Esta utilidad se ha venido utilizando con dos fines: para reparaciones de sistema de archivos y para validaciones de dichos sistemas.
Reparación de sistema de archivos
En los sistemas de archivos tradicionales, el método de escritura de datos es intrínsecamente vulnerable a errores imprevistos que generan incoherencias en el sistema. Debido a que un sistema de archivos tradicional no es transaccional, puede haber bloques sin referenciar, recuentos de vínculos erróneos u otras estructuras de sistema de archivos no coherentes. La adición de diarios soluciona algunos de estos problemas, pero puede comportar otros si el registro no se puede invertir. La existencia de datos incoherentes en el disco de una configuración ZFS sólo puede ser debida a un error de hardware·(en cuyo caso, la agrupación debería haber sido redundante) o porque hay un error en el software de ZFS.
La utilidad fsck soluciona problemas conocidos específicos de sistemas de archivos UFS. Casi todos los problemas de agrupación de almacenamiento ZFS suelen estar relacionados con errores de hardware o fallos de alimentación. Muchos se pueden evitar utilizando agrupaciones redundantes. Si una agrupación se ha dañado por un error de hardware o un fallo de alimentación, consulte Reparación de daños en las agrupaciones de almacenamiento de ZFS.
Si la agrupación no es redundante, siempre existe el riesgo de que los daños en el sistema de archivos lleguen a hacer que parte o todos los datos queden inaccesibles.
Validación de sistema de archivos
Aparte de reparar sistemas de archivos, la utilidad fsck comprueba que los datos en disco no tengan problemas. El procedimiento habitual para esta tarea consiste en desmontar el sistema de archivos y ejecutar la utilidad fsck, seguramente con el sistema en modo monousuario durante el proceso. Esta situación comporta un tiempo de inactividad proporcional al tamaño del sistema de archivos que se comprueba. En lugar de hacer que una determinada utilidad realice la comprobación pertinente, ZFS brinda un mecanismo para ejecutar una comprobación rutinaria de todas las incoherencias. Esta función, denominada limpieza, se suele utilizar en la memoria y en otros sistemas como método para detectar y evitar errores antes de que deriven en errores de hardware o software.
Control de la limpieza de datos de ZFS
Cuando ZFS detecta un error, ya sea mediante el proceso de limpieza o al acceder a un archivo por algún motivo, el error se registra internamente para poder disponer de una visión general inmediata de todos los errores conocidos de la agrupación.
Limpieza explícita de datos de ZFS
La forma más sencilla de comprobar la integridad de los datos es ejecutar una limpieza explícita de todos los datos de la agrupación. Este proceso afecta a todos los datos de la agrupación y verifica que se puedan leer todos los bloques. El proceso de limpieza transcurre todo lo deprisa que permiten los dispositivos, aunque la prioridad de cualquier E/S quede por debajo de las operaciones normales. Esta operación puede incidir negativamente en el rendimiento, aunque los datos de la agrupación deberían seguir siendo utilizables casi del modo habitual. Para iniciar una limpieza explícita, utilice el comando zpool scrub. Por ejemplo:
# zpool scrub tank |
El estado de la limpieza actual puede verse mediante el comando zpool status. Por ejemplo:
# zpool status -v tank
pool: tank
state: ONLINE
scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb 2 12:54:00 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
Sólo puede haber una operación de limpieza activa por agrupación.
Con la opción -s se puede detener una operación de limpieza en curso. Por ejemplo:
# zpool scrub -s tank |
En la mayoría de los casos, una operación de limpieza para asegurar la integridad de los datos continúa hasta finalizar. Si cree que la limpieza afecta negativamente al rendimiento del sistema, puede detenerla.
La ejecución rutinaria de limpiezas garantiza la E/S continua en todos los discos del sistema. La ejecución rutinaria de limpiezas tiene el inconveniente de impedir que los discos inactivos pasen a la modalidad de bajo consumo. Si en general el sistema efectúa E/S permanentemente, o si el consumo de energía no es ningún problema, se puede prescindir de este tema.
Para obtener más información sobre la interpretación de la salida de zpool status, consulte Consulta del estado de una agrupación de almacenamiento de ZFS.
Limpieza y actualización de la duplicación de datos de ZFS
Al reemplazar un dispositivo, se inicia una operación de actualización de duplicación de datos para transferir datos de las copias correctas al nuevo dispositivo. Este proceso es una forma de limpieza de disco. Por lo tanto, una acción de este tipo sólo puede darse en la agrupación en un momento determinado. Si hay una operación de limpieza en curso, una operación de actualización de duplicación de datos suspende la limpieza en curso y la reinicia una vez concluida la actualización de duplicación.
Para obtener más información sobre la actualización de duplicación de datos, consulte Visualización del estado de la actualización de duplicación de datos.
Solución de problemas con ZFS
En las secciones siguientes se explica la manera de identificar y resolver problemas en los sistemas de archivos o agrupaciones de almacenamiento de ZFS:
-
Cómo establecer si una agrupación de almacenamiento de ZFS tiene problemas
-
Creación de informes del sistema sobre mensajes de error de ZFS
Las funciones siguientes son válidas para identificar problemas en la configuración de ZFS:
-
Se puede mostrar información detallada de agrupaciones de almacenamiento de ZFS utilizando el comando zpool status.
-
Las notificaciones de errores en agrupaciones y dispositivos se realizan través de mensajes de diagnóstico de ZFS/FMA.
-
Los comandos anteriores de ZFS que modificaban la información sobre el estado de las agrupaciones se ven ahora mediante el comando zpool history.
Casi todas las resoluciones de problemas de ZFS implican el uso del comando zpool status. Este comando analiza los errores de un sistema e identifica el problema más grave, sugiere una acción y proporciona un vínculo a documentación técnica para obtener más información. Aunque pueda haber varios problemas, el comando sólo identifica un problema de la agrupación. Por ejemplo, los errores de datos dañados generalmente denotan que ha fallado alguno de los dispositivos, pero la sustitución del dispositivo defectuoso podría no solucionar todos los problemas de deterioro de datos.
Además, un motor de diagnóstico de ZFS detecta y notifica errores de agrupaciones y dispositivos. También se notifican errores de suma de comprobación, E/S, dispositivos y agrupaciones asociados con errores de dispositivos o agrupaciones. Los errores de ZFS indicados por fmd se muestran en la consola y el archivo de mensajes del sistema. En la mayoría de los casos, el mensaje de fmd remite al comando zpool status para obtener más instrucciones sobre recuperación.
A continuación se expone el proceso básico de recuperación:
-
Si procede, utilice el comando zpool history para identificar los comandos de ZFS anteriores que han desembocado en la situación de error. Por ejemplo:
# zpool history tank History for 'tank': 2010-07-15.12:06:50 zpool create tank mirror c0t1d0 c0t2d0 c0t3d0 2010-07-15.12:06:58 zfs create tank/erick 2010-07-15.12:07:01 zfs set checksum=off tank/erick
Las sumas de comprobación de esta salida están inhabilitadas para el sistema de archivos tank/erick. No se recomienda esta configuración.
-
Identifique los errores mediante los mensajes de fmd que aparecen en la consola del sistema o en el archivo /var/adm/messages.
-
El comando zpool status -x proporciona más instrucciones de reparación.
-
Repare los fallos, mediante las siguientes operaciones:
-
Sustitución del dispositivo defectuoso o ausente y conexión del mismo.
-
Restauración de la configuración defectuosa o los datos dañados a partir de una copia de seguridad.
-
Verificación de la recuperación mediante el comando zpool status - x.
-
Copia de seguridad de la configuración que se ha restaurado, si procede.
-
En esta sección se explica la forma de interpretar la salida zpool status para diagnosticar el tipo de fallos que se pueden producir. Si bien el comando ejecuta automáticamente casi todo el proceso, es importante comprender con exactitud los problemas que se identifican para poder diagnosticar el tipo de error. Las siguientes secciones describen cómo solucionar los diversos problemas que pueden producirse.
Cómo establecer si una agrupación de almacenamiento de ZFS tiene problemas
La forma más fácil de determinar si un sistema tiene problemas conocidos es mediante el comando zpool status -x. Este comando sólo describe agrupaciones que presentan problemas. Si no hay agrupaciones cuyo estado es defectuoso, el comando muestra lo siguiente:
# zpool status -x all pools are healthy |
Sin el indicador -x, el comando muestra el estado completo de todas las agrupaciones (o de la agrupación solicitada, si se indica en la línea de comandos), incluso si las agrupaciones están en buen estado.
Para obtener más información sobre las opciones de línea de comandos en la salida de zpool status, consulte Consulta del estado de una agrupación de almacenamiento de ZFS.
Revisión de la salida de zpool status
La salida completa de zpool status se parece a la siguiente:
# zpool status tank
# zpool status tank
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 0 0 0 cannot open
errors: No known data errors
|
Esta salida se describe a continuación:
Información sobre el estado general de la agrupación
Esta sección de la salida de zpool status contiene los campos siguientes (algunos de ellos sólo se muestran cuando hay agrupaciones con problemas):
- pool
-
El nombre de la agrupación.
- state
-
Estado actual de la agrupación. Esta información se refiere únicamente a la capacidad de la agrupación de proporcionar el nivel pertinente de repetición.
- status
-
Describe cuál es el problema que afecta a la agrupación. Si no se detectan errores, este campo se omite.
- action
-
Acción recomendada para la reparación de errores. Si no se detectan errores, este campo se omite.
- see
-
Referencia a información técnica que contiene datos detallados sobre reparaciones. Los artículos en línea se actualizan con más frecuencia que esta guía. Por lo tanto, debe consultarlos para informarse sobre los procedimientos de reparación más recientes. Si no se detectan errores, este campo se omite.
- scrub
-
Identifica el estado actual de una operación de limpieza, que puede contener la fecha y hora de conclusión de la última operación de limpieza, una limpieza en curso o si no se ha solicitado ninguna operación de limpieza.
- errors
-
Identifica errores conocidos de datos o la ausencia de esta clase de errores.
Información de configuración de la agrupación
El campo config de la salida de zpool status describe la configuración de los dispositivos que conforman la agrupación, además de su estado y los posibles errores generados por los dispositivos. Puede mostrar uno de los estados siguientes: ONLINE, FAULTED, DEGRADED, UNAVAIL u OFFLINE. Si el estado es cualquiera de ellos menos ONLINE, significa que se pone el peligro la tolerancia a errores de la agrupación.
La segunda sección de la salida de configuración muestra estadísticas de errores. Dichos errores se dividen en tres categorías:
-
READ: errores de E/S al emitir una solicitud de lectura
-
WRITE: errores de E/S al emitir una solicitud de escritura
-
CKSUM: errores de suma de comprobación, lo que significa que el dispositivo ha devuelto datos dañados como resultado de una solicitud de lectura
Estos errores son aptos para determinar si los daños son permanentes. Una cantidad pequeña de errores de E/S puede denotar un corte temporal del suministro; una cantidad grande puede denotar un problema permanente en el dispositivo. Estos errores no necesariamente corresponden a datos dañados según la interpretación de las aplicaciones. Si el dispositivo se encuentra en una configuración redundante, los dispositivos podrían mostrar errores irreparables, aunque no aparezcan errores en el reflejo o el nivel de dispositivos RAID-Z. En estos casos, ZFS ha recuperado correctamente los datos en buen estado e intentado reparar los datos dañados a partir de réplicas existentes.
Para obtener más información sobre la interpretación de estos errores, consulte Cómo determinar el tipo de error en dispositivos.
En la última columna de la salida de zpool status se muestra información complementaria adicional. Dicha información se expande en el campo state para ayudar en el diagnóstico de modos de errores. Si un dispositivo tiene el estado FAULTED, este campo informa de si el dispositivo no está accesible o si dicho dispositivo tiene los datos dañados. Si se ejecuta la actualización de la duplicación de datos, el dispositivo muestra el progreso del proceso.
Para obtener información sobre el control del progreso de la actualización de duplicación de datos, consulte Visualización del estado de la actualización de duplicación de datos.
Estado del proceso de limpieza
La sección de limpieza de la salida de zpool status describe el estado actual de cualquier operación de limpieza explícita. Esta información es diferente de si se detectan errores en el sistema, aunque es válida para determinar la exactitud de la información sobre datos dañados. Si la última operación de limpieza ha concluido correctamente, lo más probable es que se haya detectado cualquier tipo de datos dañados.
Los mensajes de limpieza completada se mantienen entre reinicios de sistema.
Para obtener más información sobre la limpieza de datos y la forma de interpretar esa información, consulte Comprobación de integridad de sistema de archivos ZFS.
Errores de datos dañados
El comando zpool status muestra también si hay errores conocidos asociados con la agrupación. Estos errores se pueden haber detectado durante la limpieza de datos o en el transcurso del funcionamiento normal. ZFS mantiene un registro constante de todos los errores de datos asociados con una agrupación. El registro se reinicia cada vez que concluye una limpieza total del sistema.
Los errores de datos dañados siempre son fatales. El hecho de que existan denota que al menos una aplicación ha tenido un error de E/S debido a los datos dañados de la agrupación. Los errores de dispositivos en una agrupación redundante no generan datos dañados ni forman parte de este registro. De forma predeterminada, sólo se muestra el número de errores detectados. La opción zpool status -v proporciona una lista completa de errores con los detalles. Por ejemplo:
# zpool status -v
pool: tank
state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://www.sun.com/msg/ZFS-8000-HC
scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:08:42 2010
config:
NAME STATE READ WRITE CKSUM
tank UNAVAIL 0 0 0 insufficient replicas
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 4 1 0 cannot open
errors: Permanent errors have been detected in the following files:
/tank/data/aaa
/tank/data/bbb
/tank/data/ccc
|
El comando fmd muestra un mensaje parecido en la consola del sistema y el archivo /var/adm/messages. Con el comando fmdump se puede hacer un seguimiento de estos mensajes.
Para obtener más información sobre la interpretación de errores sobre corrupción de datos, consulte Identificación del tipo de deterioro de datos.
Creación de informes del sistema sobre mensajes de error de ZFS
Aparte de hacer un constante seguimiento de los errores en la agrupación, ZFS muestra mensajes de syslog cuando se generan eventos de interés. Las situaciones siguientes generan eventos que notificar al administrador:
-
Transición de estados del dispositivo: si un dispositivo pasa a tener el estado FAULTED, ZFS registra un mensaje que indica que la tolerancia a errores de la agrupación puede estar en peligro. Se envía un mensaje parecido si el dispositivo se conecta posteriormente, con lo cual la agrupación se recupera del error.
-
Datos dañados: si se detecta cualquier tipo de datos dañados, ZFS registra un mensaje en el que se indica su ubicación y el momento en que tiene lugar. Este mensaje se registra sólo la primera vez que se detecta. Los accesos posteriores no generan ningún mensaje.
-
Errores de agrupaciones y de dispositivos: si tiene lugar un error de agrupación o dispositivo, el daemon del administrador de errores informa de dichos errores mediante mensajes de syslog y mediante el comando fmdump.
Si ZFS detecta un error de dispositivo y se recupera automáticamente, no se genera ninguna notificación. Esta clase de errores no supone ningún fallo en la redundancia de la agrupación ni la integridad de los datos. Además, esta clase de errores suele ser fruto de un problema de controlador provisto de su propio conjunto de mensajes de error.
Reparación de una configuración de ZFS dañada
ZFS mantiene una caché de agrupaciones activas y su configuración en el sistema de archivos raíz. Si este archivo se daña o se desincroniza respecto a la información de configuración que se almacena en disco, no se podrá abrir la agrupación. ZFS procura evitar esta situación, si bien siempre se pueden producir daños arbitrarios debido a la naturaleza del almacenamiento subyacente. Al final termina desapareciendo una agrupación del sistema cuando lo normal es que estuviera disponible. Esta situación también puede presentarse como una configuración parcial en la que falta un número no determinado de dispositivos virtuales de nivel superior. Sea como sea, la configuración se puede recuperar exportando la agrupación (si está visible) y volviéndola a importar.
Para obtener información sobre importación y exportación de agrupaciones, consulte Migración de agrupaciones de almacenamiento de ZFS.
Resolución de un dispositivo que no se encuentra
Si no se puede abrir un dispositivo, se muestra como UNAVAIL en la salida de zpool status. Este estado indica que ZFS no ha podido abrir el dispositivo la primera vez que se accedió a la agrupación, o que desde entonces el dispositivo ya no está disponible. Si el dispositivo hace que no quede disponible un dispositivo virtual de alto nivel, la agrupación queda completamente inaccesible. De lo contrario, podría verse en peligro la tolerancia a errores de la agrupación. En cualquier caso, sólo tiene que volver a conectar el dispositivo al sistema para restablecer el funcionamiento normal.
Por ejemplo, en pantalla puede aparecer un mensaje parecido al siguiente procedente de fmd tras un error de dispositivo:
SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Thu Jun 24 10:42:36 PDT 2010 PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo2 SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: a1fb66d0-cc51-cd14-a835-961c15696fcb DESC: The number of I/O errors associated with a ZFS device exceeded acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt will be made to activate a hot spare if available. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device. |
Para ver información más pormenorizada del problema y la resolución, utilice el comando zpool status -x. Por ejemplo:
# zpool status -x
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:15:20 2010
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 0 0 0 cannot open
errors: No known data errors
|
En esta salida puede observarse que el dispositivo c1t1d0 ausente no funciona. Si determina que se trata de un dispositivo defectuoso, sustitúyalo.
A continuación, utilice el comando zpool online para conectar el dispositivo reemplazado. Por ejemplo:
# zpool online tank c1t1d0 |
Como último paso, confirme que la agrupación con el dispositivo reemplazado está en buen estado. Por ejemplo:
# zpool status -x tank pool 'tank' is healthy |
Cómo volver a conectar físicamente un dispositivo
La forma de volver a conectar un dispositivo que falta depende del tipo de dispositivo. Si es una unidad de red, se debe restaurar la conectividad a la red. Si se trata de un dispositivo USB u otro medio extraíble, debe volverse a conectar al sistema. Si consiste en un disco local, podría haber fallado un controlador de tal forma que el dispositivo ya no estuviera visible en el sistema. En tal caso, el controlador se debe reemplazar en el punto en que los discos vuelvan a estar disponibles. Pueden darse otros problemas, según el tipo de hardware y su configuración. Si una unidad falla y ya no está visible en el sistema, el dispositivo debe tratarse como si estuviera dañado. Siga los procedimientos que se indican en Sustitución o reparación de un dispositivo dañado.
Notificación de ZFS sobre disponibilidad de dispositivos
Después de que un dispositivo se vuelve a conectar al sistema, ZFS puede detectar o no automáticamente su disponibilidad. Si la agrupación ya tenía errores o el sistema se reinició como parte del procedimiento de conexión, ZFS vuelve a explorar automáticamente todos los dispositivos cuando intenta abrir la agrupación. Si la agrupación se había degradado y el dispositivo se reemplazó cuando el sistema estaba en ejecución, se debe notificar a ZFS que el dispositivo ya está disponible y listo para abrirse de nuevo mediante el comando zpool online. Por ejemplo:
# zpool online tank c0t1d0 |
Para obtener más información sobre la conexión de dispositivos, consulte Cómo conectar un dispositivo.
Sustitución o reparación de un dispositivo dañado
Esta sección describe la forma de determinar tipos de errores en dispositivos, eliminar errores transitorios y reemplazar un dispositivo.
Cómo determinar el tipo de error en dispositivos
El concepto dispositivo dañado es bastante ambiguo; puede referirse a varias situaciones:
-
Deterioro de bits: con el tiempo, eventos aleatorios como campos magnéticos o rayos cósmicos pueden causar anomalías en los bits almacenados en el disco. Son eventos relativamente poco frecuentes, pero lo suficientemente habituales como para causar daños en datos de sistemas grandes o con procesos de larga duración.
-
Lecturas o escrituras de ubicaciones incorrectas: los errores de firmware o hardware pueden hacer que lecturas o escrituras de bloques enteros hagan referencia a ubicaciones incorrectas en el disco. Suelen ser errores transitorios, pero si se producen en grandes cantidades podrían denotar una unidad defectuosa.
-
Error de administrador: los administradores pueden sobrescribir inadvertidamente porciones del disco con datos dañados (por ejemplo, sobrescribir porciones de /dev/zero en el disco) que afectarán disco de manera permanente. Estos errores siempre son transitorios.
-
Interrupción temporal del suministro de energía– Durante un determinado periodo de tiempo, quizá no se pueda acceder a un disco, lo que puede provocar errores de E/S. Esta situación se suele asociar con dispositivos conectados a redes, aunque los discos locales también pueden sufrir interrupciones temporales de suministro de energía. Estos errores pueden ser transitorios o no.
-
Hardware dañado o inestable: esta situación constituye un cajón de sastre de todos los problemas que puede presentar un hardware defectuoso, entre los que se pueden citar errores persistentes de E/S y transportes defectuosos que causan errores aleatorios. Estos errores suelen ser permanentes.
-
Dispositivo sin conexión: si un dispositivo está sin conexión, se supone que el administrador le ha asignado este estado porque presenta algún problema. El administrador que asigna este estado al dispositivo puede establecer si dicha suposición es correcta.
El diagnóstico exacto de la naturaleza del problema puede resultar un proceso complicado. El primer paso es examinar la cantidad de errores en la salida de zpool status. Por ejemplo:
# zpool status -v tpool
pool: tpool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h0m with 2 errors on Tue Jul 13 11:08:37 2010
config:
NAME STATE READ WRITE CKSUM
tpool ONLINE 2 0 0
c1t1d0 ONLINE 2 0 0
c1t3d0 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
/tpool/words
|
Los errores pueden ser de E/S o de suma de comprobación, y pueden denotar el posible tipo de defecto. El funcionamiento normal prevé muy pocos errores (sólo unos pocos en periodos de tiempo prolongados). Si detecta una gran cantidad de errores, probablemente denote la inminencia de un error o la inutilización completa de un dispositivo. Pero un error de administrador también puede derivar en grandes cantidades de errores. El registro del sistema syslog es la otra fuente de información. Si el registro tiene una gran cantidad de mensajes de controlador de canal de fibra o SCSI, es probable que la situación sea sintomática de graves problemas de hardware. Si no se generan mensajes de syslog, es probable que los daños sean transitorios.
El objetivo es responder a la pregunta siguiente:
¿Es probable que este dispositivo vuelva a tener un error?
Los errores que suceden sólo una vez se consideran transitorios y no denotan problemas potenciales. Los errores continuos o suficientemente graves como para indicar problemas potenciales en el hardware se consideran errores fatales. El hecho de determinar el tipo de error trasciende el ámbito de cualquier software automatizado que haya actualmente en ZFS, por lo cual eso es una tarea propia de los administradores. Una vez determinado el error, se puede llevar a cabo la acción pertinente. Suprima los errores transitorios o reemplace los dispositivos con errores fatales. Estos procedimientos de reparación se explican en las secciones siguientes.
Aun en caso de que los errores de dispositivos se consideren transitorios, se pueden haber generado errores incorregibles en los datos de la agrupación. Estos errores precisan procedimientos especiales de reparación, incluso si el dispositivo subyacente se considera que está en buen estado o se ha reparado. Para obtener más información sobre cómo reparar errores de datos, consulte Reparación de datos dañados.
Supresión de errores transitorios
Si los errores en dispositivos se consideran transitorios, en el sentido de que es poco probable que incidan más adelante en el buen estado del dispositivo, se pueden suprimir tranquilamente para indicar que no se ha producido ningún error fatal. Para suprimir los recuentos de errores de RAID-Z o dispositivos reflejados, utilice el comando zpool clear. Por ejemplo:
# zpool clear tank c1t1d0 |
Esta sintaxis suprime todos los errores de dispositivo y recuentos de errores de datos asociados con el dispositivo.
Utilice la sintaxis siguiente para suprimir todos los errores asociados con los dispositivos virtuales de una agrupación y para suprimir los recuentos de errores de datos asociados con la agrupación:
# zpool clear tank |
Para obtener más información sobre la supresión de errores de dispositivos, consulte Borrado de errores de dispositivo de agrupación de almacenamiento.
Sustitución de un dispositivo de una agrupación de almacenamiento de ZFS
Si los daños en un dispositivo son permanentes o es posible que lo sean en el futuro, dicho dispositivo debe reemplazarse. El hecho de que el dispositivo pueda sustituirse o no depende de la configuración.
-
Sustitución de un dispositivo de una agrupación de almacenamiento de ZFS
-
Visualización del estado de la actualización de duplicación de datos
Cómo determinar si un dispositivo se puede reemplazar o no
Para que un dispositivo se pueda reemplazar, la agrupación debe tener el estado ONLINE. El dispositivo debe formar parte de una configuración redundante o tener el estado correcto (en estado ONLINE). Si el dispositivo forma parte de una configuración redundante, debe haber suficientes réplicas desde las que poder recuperar datos en buen estado. Si dos discos con reflejo de cuatro vías son defectuosos, se puede reemplazar cualquiera de ellos porque se dispone de réplicas en buen estado. Sin embargo, si hay dos discos defectuosos en un dispositivo virtual RAID-Z (raidz1) de cuatro vías, ninguno de ellos se puede reemplazar porque no se dispone de suficientes réplicas desde las que recuperar datos. Si el dispositivo está dañado pero tiene conexión, se puede reemplazar siempre y cuando la agrupación no tenga el estado FAULTED. Sin embargo, cualquier dato dañado del dispositivo se copia al nuevo dispositivo a menos que haya suficientes réplicas con datos correctos.
En la configuración siguiente, el disco c1t1d0 se puede reemplazar y los datos de la agrupación se copian de la réplica en buen estado, c1t0d0.
mirror DEGRADED
c1t0d0 ONLINE
c1t1d0 FAULTED
|
El disco c1t0d0 también se puede reemplazar, aunque no es factible la recuperación automática de datos debido a la falta de réplicas en buen estado.
En la configuración siguiente, no se puede reemplazar ninguno de los discos dañados. Los discos con el estado ONLINE tampoco pueden reemplazarse porque la agrupación está dañada.
raidz FAULTED
c1t0d0 ONLINE
c2t0d0 FAULTED
c3t0d0 FAULTED
c4t0d0 ONLINE
|
En la configuración siguiente, el disco de nivel superior tampoco se puede reemplazar, si bien en el disco nuevo se va a copiar cualquier dato dañado.
c1t0d0 ONLINE c1t1d0 ONLINE |
Si cualquiera de los discos es defectuoso, no se puede reemplazar porque la agrupación también está dañada.
Dispositivos que no se pueden reemplazar
Si la pérdida de un dispositivo causa el deterioro de la agrupación, o el dispositivo contiene demasiados errores en los datos en una configuración no redundante, la correcta sustitución del dispositivo no es factible. Si la redundancia es insuficiente, no es posible restaurar con datos en buen estado el dispositivo dañado. En este caso, la única posibilidad es destruir la agrupación, volver a crear la configuración y, a continuación, restaurar los datos desde una copia de seguridad.
Para obtener más información sobre cómo restaurar toda una agrupación, consulte Reparación de daños en las agrupaciones de almacenamiento de ZFS.
Sustitución de un dispositivo de una agrupación de almacenamiento de ZFS
Tras determinar que se puede reemplazar un dispositivo, utilice el comando zpool replace para reemplazarlo. Si va a reemplazar el dispositivo dañado con otro diferente, utilice sintaxis como ésta:
# zpool replace tank c1t1d0 c2t0d0 |
Este comando migra datos al dispositivo nuevo desde el dispositivo dañado, o de otros dispositivos de la agrupación si la configuración es redundante. Cuando finaliza el comando, desconecta el dispositivo dañado de la configuración. Es entonces cuando el dispositivo se puede eliminar del sistema. Si ya ha eliminado el dispositivo y lo ha reemplazado por uno nuevo en la misma ubicación, utilice la forma de un solo dispositivo del comando. Por ejemplo:
# zpool replace tank c1t1d0 |
Este comando selecciona un disco sin formato, le aplica el formato correspondiente y actualiza la duplicación de datos a partir del resto de la configuración.
Para obtener más información acerca del comando zpool replace, consulte Sustitución de dispositivos en una agrupación de almacenamiento.
Ejemplo 11–1 Sustitución de un dispositivo de una agrupación de almacenamiento de ZFS
El ejemplo siguiente muestra cómo reemplazar un dispositivo (c1t3d0) en la agrupación de almacenamiento reflejada tank en un sistema Sun Fire x4500 de Oracle. Para reemplazar el disco c1t3d0 con un nuevo disco en la misma ubicación (c1t3d0), desconfigure el disco antes de intentar reemplazarlo. Los pasos básicos son:
-
Desconectar el disco (c1t3d0) que se va a sustituir. No puede desconfigurar un disco que se esté utilizando.
-
Utilizar el comando cfgadm para identificar el disco (c1t3d0) que desconfigurar y desconfigurarlo. La agrupación se degradará con el disco desconectado en esta configuración reflejada, pero la agrupación seguirá estando disponible.
-
Sustituir físicamente el disco (c1t3d0). Antes de quitar la unidad que falla, asegúrese de que se encienda el LED azul que indica que el disco está listo para quitar.
-
Volver a configurar el disco (c1t3d0).
-
Conectar el disco nuevo (c1t3d0).
-
Ejecutar el comando zpool replace para reemplazar el disco (c1t3d0).
Nota –Si ha configurado previamente la propiedad de agrupación autoreplace como on, se dará formato y se sustituirá automáticamente cualquier dispositivo nuevo que se detecte en la misma ubicación física como dispositivo que antes pertenecía a la agrupación, mediante el comando zpool replace. Es posible que el hardware no sea compatible con esta función.
-
Si un disco fallido se sustituye automáticamente por un repuesto en marcha, puede que deba desconectarlo después de dicha sustitución. Por ejemplo, si c2t4d0 es aún un repuesto en marcha activo después de sustituir el disco fallido, desconéctelo.
# zpool detach tank c2t4d0
El ejemplo siguiente detalla los pasos para reemplazar un disco en una agrupación de almacenamiento de ZFS.
# zpool offline tank c1t3d0
# cfgadm | grep c1t3d0
sata1/3::dsk/c1t3d0 disk connected configured ok
# cfgadm -c unconfigure sata1/3
Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3
This operation will suspend activity on the SATA device
Continue (yes/no)? yes
# cfgadm | grep sata1/3
sata1/3 disk connected unconfigured ok
<Physically replace the failed disk c1t3d0>
# cfgadm -c configure sata1/3
# cfgadm | grep sata1/3
sata1/3::dsk/c1t3d0 disk connected configured ok
# zpool online tank c1t3d0
# zpool replace tank c1t3d0
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
c0t3d0 ONLINE 0 0 0
c1t3d0 ONLINE 0 0 0
errors: No known data errors
|
Tenga en cuenta que el comando zpool output anterior podría mostrar tanto los discos nuevos como los antiguos en un encabezado replacing. Por ejemplo:
replacing DEGRADED 0 0 0 c1t3d0s0/o FAULTED 0 0 0 c1t3d0 ONLINE 0 0 0 |
Este texto indica que el proceso de sustitución está en curso y se está actualizando la duplicación de datos.
Si va a reemplazar un disco (c1t3d0) con otro (c4t3d0), sólo tiene que ejecutar el comando zpool replace. Por ejemplo:
# zpool replace tank c1t3d0 c4t3d0
# zpool status
pool: tank
state: DEGRADED
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 DEGRADED 0 0 0
c0t3d0 ONLINE 0 0 0
replacing DEGRADED 0 0 0
c1t3d0 OFFLINE 0 0 0
c4t3d0 ONLINE 0 0 0
errors: No known data errors
|
Es posible que deba ejecutar el comando zpool status varias veces hasta finalizar la sustitución del disco.
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
c0t3d0 ONLINE 0 0 0
c4t3d0 ONLINE 0 0 0
|
Ejemplo 11–2 Sustitución de un dispositivo de registro que presenta errores
El ejemplo siguiente muestra cómo recuperar un dispositivo de registro (c0t5d0) que presenta errores en la agrupación de almacenamiento, (pool). Los pasos básicos son:
-
Revisar el resultado de zpool status -x y el mensaje de diagnóstico de FMA que se describen a continuación:
-
Reemplazar físicamente el dispositivo de registro que presenta errores.
-
Conectar el dispositivo de registro.
-
Borrar la condición de error de la agrupación.
# zpool status -x
pool: pool
state: FAULTED
status: One or more of the intent logs could not be read.
Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
or ignore the intent log records by running 'zpool clear'.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
pool FAULTED 0 0 0 bad intent log
mirror ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c0t4d0 ONLINE 0 0 0
logs FAULTED 0 0 0 bad intent log
c0t5d0 UNAVAIL 0 0 0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool
|
# zpool status -x
pool: pool
state: FAULTED
status: One or more of the intent logs could not be read.
Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
or ignore the intent log records by running 'zpool clear'.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
pool FAULTED 0 0 0 bad intent log
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c0t4d0 ONLINE 0 0 0
logs FAULTED 0 0 0 bad intent log
c0t5d0 UNAVAIL 0 0 0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool
|
Visualización del estado de la actualización de duplicación de datos
El proceso de reemplazar un dispositivo puede tardar una considerable cantidad de tiempo, según el tamaño del dispositivo y la cantidad de datos que haya en la agrupación. El proceso de transferir datos de un dispositivo a otro, denominado actualización de la duplicación de datos, se puede controlar mediante el comando zpool status.
Los sistemas de archivos tradicionales actualizan duplicaciones de datos en los bloques. Debido a que ZFS suprime la disposición artificial de capas de Volume Manager, puede ejecutar la actualización de duplicación de datos de manera más potente y controlada. Esta función presenta dos ventajas principales:
-
ZFS sólo actualiza la duplicación de los datos necesarios. En caso de una breve interrupción del suministro (en contraposición a un reemplazo completo del dispositivo), la actualización de duplicación de datos del disco puede hacerse en cuestión de segundos, Si se reemplaza todo un disco, el tiempo que implica el proceso de actualización de duplicación de datos es proporcional a la cantidad de datos que se utilizan en disco. La sustitución de un disco de 500 GB puede ser cuestión de segundos si la agrupación sólo tiene unos cuantos gigabytes de espacio usado en el disco.
-
La actualización de duplicación de datos es un proceso seguro que se puede interrumpir. Si el sistema se queda sin conexión o se reinicia, el proceso de actualización de duplicación de datos reanuda la tarea exactamente en el punto en que se había interrumpido, sin que haga falta hacer nada.
Para observar el progreso de la actualización de duplicación de datos, utilice el comando zpool status. Por ejemplo:
# zpool status tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h0m, 22.60% done, 0h1m to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
c1t0d0 UNAVAIL 0 0 0 cannot open
c2t0d0 ONLINE 0 0 0 85.0M resilvered
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
En este ejemplo, el disco c1t0d0 se sustituye por c2t0d0. Este evento se refleja en la salida del estado mediante la presencia del dispositivo virtual que reemplaza en la configuración. Este dispositivo no es real ni sirve para crear una agrupación. La única finalidad de este dispositivo es mostrar el proceso de actualización de duplicación de datos e identificar el dispositivo que se va a reemplazar.
Cualquier agrupación sometida al proceso de actualización de duplicación de datos adquiere el estado ONLINE o DEGRADED, porque hasta que no haya finalizado dicho proceso es incapaz de proporcionar el nivel necesario de redundancia. La actualización de duplicación de datos se ejecuta lo más deprisa posible, si bien la E/S siempre se programa con una prioridad inferior a la E/S solicitada por el usuario, para que repercuta en el sistema lo menos posible. Tras finalizarse la actualización de duplicación de datos, la configuración asume los parámetros nuevos. Por ejemplo:
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h1m with 0 errors on Tue Feb 2 13:54:30 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0 377M resilvered
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
La agrupación pasa de nuevo al estado ONLINE y el disco dañado original (c1t0d0) desaparece de la configuración.
Reparación de datos dañados
En las secciones siguientes se explica el procedimiento para identificar el tipo de corrupción de datos y, si es factible, cómo reparar los datos.
Para reducir al mínimo las posibilidades de que los datos sufran daños, ZFS utiliza sumas de comprobación, redundancia y datos que se reparan a sí mismos. Ahora bien, los datos se pueden dañar si una agrupación no es redundante, cuando una agrupación está en estado "degraded" o si se combina una improbable serie de eventos para dañar varias copias de determinados datos. Sea cual sea el origen, el resultado es el mismo: los datos quedan dañados y no se puede acceder a ellos. Las medidas requeridas dependen del tipo de datos dañados y su valor relativo. Se pueden dañar dos tipos básicos de datos:
-
Metadatos de agrupación: para abrir una agrupación y acceder a conjuntos de datos, ZFS debe analizar cierta cantidad de datos. Si se dañan estos datos, quedará inaccesible toda la agrupación o partes de la jerarquía del conjuntos de datos.
-
Datos de objeto: en este caso, el daño afecta a un determinado archivo o directorio. Ello puede hacer que no sea posible acceder a una parte del archivo o directorio, o causar la interrupción del objeto.
Los datos se verifican durante el funcionamiento normal y durante el proceso de limpieza. Para obtener más información sobre cómo verificar la integridad de datos de agrupaciones, consulte Comprobación de integridad de sistema de archivos ZFS.
Identificación del tipo de deterioro de datos
De forma predeterminada, el comando zpool status avisa únicamente de la presencia de daños, pero no indica su ubicación. Por ejemplo:
# zpool status monkey
pool: monkey
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
monkey ONLINE 8 0 0
c1t1d0 ONLINE 2 0 0
c2t5d0 ONLINE 6 0 0
errors: 8 data errors, use '-v' for a list
|
Cada error indica solamente que ha habido un error en un determinado momento. Eso no significa que cada error siga estando en el sistema. Éste es el caso en circunstancias normales. Determinadas interrupciones temporales del suministro pueden comportar daños en los datos que se reparan automáticamente cuando finaliza dicha interrupción. Se garantiza la ejecución completa de un proceso de limpieza de la agrupación para examinar cada bloque activo de la agrupación, con lo cual el registro de errores se reinicia cuando concluye la limpieza. Si considera que ya no hay errores y no quiere esperar a que finalice la limpieza, reinicie todos los errores de la agrupación mediante el comando zpool online.
Si los dañados afectan a metadatos de toda la agrupación, la salida difiere ligeramente. Por ejemplo:
# zpool status -v morpheus
pool: morpheus
id: 1422736890544688191
state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
see: http://www.sun.com/msg/ZFS-8000-72
config:
morpheus FAULTED corrupted data
c1t10d0 ONLINE
|
Si los daños afectan a toda la agrupación, ésta pasa al estado FAULTED , ya que posiblemente no podrá proporcionar el nivel de redundancia requerido.
Reparación de un archivo o directorio dañado
Si un archivo o directorio resultasen dañados, según el tipo de corrupción, el sistema podría seguir funcionando. Si en el sistema no hay copias de los datos de buena calidad, cualquier daño que tenga lugar será irreparable. Si los datos son importantes, la única alternativa es recuperarlos a partir de una copia de seguridad. Aun así, debe poder realizar una recuperación sin necesidad de restaurar toda la agrupación.
Si se ha dañado un bloque datos de archivo, el archivo se puede eliminar sin problemas; de este modo, el error desaparece del sistema. Utilice el comando zpool status -v para ver en pantalla una lista con nombres de archivos que tienen errores constantes. Por ejemplo:
# zpool status -v
pool: monkey
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
monkey ONLINE 8 0 0
c1t1d0 ONLINE 2 0 0
c2t5d0 ONLINE 6 0 0
errors: Permanent errors have been detected in the following files:
/monkey/a.txt
/monkey/bananas/b.txt
/monkey/sub/dir/d.txt
monkey/ghost/e.txt
/monkey/ghost/boo/f.txt
|
La lista de nombres de archivos con errores constantes se puede describir del modo siguiente:
-
Si se busca la ruta de acceso del archivo y se monta el conjunto de datos, se muestra en pantalla toda la ruta del archivo. Por ejemplo:
/monkey/a.txt
-
Si se busca la ruta de acceso del archivo pero el conjunto de datos no se monta, en pantalla se muestra el nombre del conjunto de datos sin una barra inclinada (/), seguido de la ruta de acceso del conjunto de datos al archivo. Por ejemplo:
monkey/ghost/e.txt
-
Si no se puede trasladar correctamente el número de objeto a una ruta de archivo, ya sea por un error o porque el objeto no tiene asociada ninguna ruta de archivo auténtica, como en el caso de dnode_t, en pantalla se muestra nombre del conjunto de datos seguido del número de objeto. Por ejemplo:
monkey/dnode:<0x0>
-
Si se daña un objeto del conjunto de metaobjetos, en pantalla se muestra un etiqueta especial de <metadata>, seguida del número de objeto.
Si los daños se dan en un directorio o en los metadatos de un archivo, la única alternativa es colocar el archivo en otra ubicación. Puede colocar cualquier archivo o directorio en una ubicación menos apropiada para poder restaurar el objeto original.
Reparación de daños en las agrupaciones de almacenamiento de ZFS
Si los metadatos de una agrupación resultan dañados de forma que no es posible abrir la agrupación o importarla, puede optar por:
-
Intentar recuperar la agrupación mediante uno de los comandos zpool clear - F o zpool import -F. Estos comandos intentan restaurar un estado operativo de las transacciones de agrupación más recientes. Puede utilizar el comando zpool status para revisar una agrupación dañada y el procedimiento de recuperación recomendado. Por ejemplo:
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4El proceso de recuperación descrito anteriormente consiste en utilizar el comando:
# zpool clear -F tpool
Si intenta importar una agrupación de almacenamiento dañada, se muestran mensajes parecidos al siguiente:
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery.El proceso de recuperación descrito anteriormente consiste en utilizar el comando:
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions
Si la agrupación dañada está en el archivo zpool.cache, el problema se descubre al iniciar el sistema, y dicha agrupación se notifica en el comando zpool status. Si la agrupación no está en el archivo zpool.cache, no se importará o abrirá correctamente y aparecerán mensajes de agrupación dañada al intentar importarla.
-
Si la agrupación no se puede recuperar con el método de recuperación descrito anteriormente, deberá restaurar la agrupación y todos sus datos desde una copia de seguridad. Los procedimientos para ello son muy variados: dependen de la configuración de las agrupaciones y de la estrategia de las copias de seguridad. En primer lugar, guarde la configuración tal como aparece en el comando zpool status para poder crearla de nuevo después de destruida la agrupación. A continuación, utilice el comando zpool destroy -f para destruir la agrupación. Asimismo, conserve un archivo que contenga la disposición de los conjuntos de datos y guarde en lugar seguro las distintas propiedades que se han definido, ya que si en algún momento no se puede acceder a la agrupación, tampoco se podrá acceder a esta información. A partir de la configuración de la agrupación y la disposición del conjunto de datos, es posible reconstruir toda la configuración tras la destrucción de la agrupación. Los datos se pueden rellenar utilizando cualquier método de restauración o copia de seguridad.
Reparación de un sistema que no se puede iniciar
ZFS se ha concebido para mantenerse robusto y estable frente a los errores. Aun así, los errores de software o problemas imprevistos pueden desequilibrar el sistema al intentar acceder a una agrupación. Como parte del proceso de inicio se debe abrir cada agrupación, lo que significa que esta clase de errores harán que el sistema entre en un bucle de inicios de emergencia. Para solucionar esta situación, debe indicar a ZFS que no busque agrupaciones al inicio.
ZFS mantiene una caché interna de agrupaciones disponibles junto con sus configuraciones en /etc/zfs/zpool.cache. La ubicación y el contenido de este archivo son personales y susceptibles de cambiarse. Si el sistema no se puede iniciar, inicie en none mediante la opción -m =none. Cuando el sistema se haya iniciado, vuelva a montar el sistema de archivos raíz como grabable y cambie el nombre o cambie la ubicación del archivo /etc/zfs/zpool.cache. Estas acciones hacen que ZFS no tenga en cuenta que en el sistema hay agrupaciones, lo cual impide que intente acceder a la agrupación dañada que causa el problema. A continuación, puede pasar a un estado normal del sistema mediante el comando svcadm milestone all. Se puede aplicar un proceso similar al iniciar desde un sistema de archivos raíz alternativo para efectuar reparaciones.
Cuando el sistema se haya iniciado, puede intentar importar la agrupación mediante el comando zpool import. Sin embargo, es probable que se cause el mismo error que al inicio, puesto que el comando emplea el mismo mecanismo de acceso a agrupaciones. Si en el sistema hay varias agrupaciones, haga lo siguiente:
-
Cambie el nombre de zpool.cache o lleve el archivo a otra ubicación, tal como se ha indicado anteriormente.
-
Determine qué agrupación podría tener problemas utilizando el comando fmdump -eV, para ver las agrupaciones que han notificado errores fatales.
-
Importe una por una las agrupaciones que tienen problemas, como se describe en la salida de fmdump.
- © 2010, Oracle Corporation and/or its affiliates