¿Puede un espejo ZFS utilizar unidades con diferentes tamaños de sector?

Puede, pero el vdev utiliza una política de ashift y el requisito de sector físico más grande debe prevalecer para evitar penalizaciones de lectura-modificación-escritura.

La decisión es importante cuando una unidad de reemplazo informa de sectores físicos de 4K, mientras que el miembro superviviente del espejo se creó con una alineación menor. Los dos estados en conflicto son una geometría de vdev compatible y un ashift fijo subóptimo o una discrepancia de capacidad. Comience con una configuración guardada y datos desechables, observe una rama a la vez y deténgase si la prueba aumenta el riesgo de pérdida de datos, permisos o disponibilidad.

Defina las condiciones detrás de la decisión sobre un espejo ZFS con sectores mixtos

Registre el entorno antes de cambiar nada: versiones del software y del firmware, identidades de los dispositivos, ruta de montaje o de red, espacio libre, permisos y síntoma observable. La línea base debe conservar suficientes detalles para reproducir que una unidad de reemplazo informa de sectores físicos de 4K mientras que el miembro superviviente del espejo se creó con una alineación menor.

El primer candidato es una geometría de vdev compatible. El segundo es un ashift fijo subóptimo o una discrepancia de capacidad. La propiedad ashift de OpenZFS actual define el mecanismo o el límite de comandos utilizado en la prueba; no sustituye la observación de este servidor doméstico específico.

Escriba la condición de aceptación y la condición de detención antes de ejecutar el discriminador. Una prueba superada debe cambiar la evidencia predicha por una rama y dejar sin cambios los servicios no relacionados; una prueba fallida debe devolver el sistema al estado guardado en lugar de activar una cadena de correcciones especulativas.

Pruebe la afirmación sin reducir el requisito original

Use este discriminador: inspeccione el ashift existente y los informes de sectores lógicos y físicos de la unidad; después, compare el rendimiento de escrituras alineadas en un pool réplica. Mantenga constantes la carga de trabajo, el cliente, la ruta, el conjunto de archivos y los tiempos para que el resultado pueda atribuirse a la variable modificada.

Use el comportamiento de zpool en FreeBSD para seleccionar el campo que realmente pueda separar las ramas; después, capture su marca de tiempo, estado de salida, texto del error, identidad del dispositivo o de la instantánea, latencia, bytes transferidos, permisos y estado de recuperación. Una salida limpia del comando no es suficiente cuando la identidad, la durabilidad o el estado de la aplicación son la afirmación que se está probando.

Repita la prueba una vez después de un reinicio, una reconexión, un remontaje o una caché fría cuando ese evento forme parte de la condición original. Si la primera ejecución es destructiva o el entorno no puede restaurarse, deténgase y reproduzca la prueba en una copia desechable.

zpool get ashift pool
lsblk -o NAME,LOG-SEC,PHY-SEC,SIZE

Interprete los resultados superados, fallidos y excepcionales

APROBADO: el reemplazo se conecta, la resilverización se completa y la latencia de las escrituras alineadas sigue siendo aceptable. Registre la versión exacta, la identidad y la carga de trabajo que superaron la prueba para que la conclusión siga siendo condicional en lugar de convertirse en una afirmación universal.

FALLIDO: el ashift es demasiado pequeño, el reemplazo es ligeramente más pequeño o el rendimiento se degrada con escrituras síncronas y aleatorias. Un fallo no demuestra automáticamente la rama opuesta cuando la red, la memoria, los permisos o la coherencia de origen pueden influir en ambas; aísle esas dependencias compartidas antes de escalar.

RESULTADO EXCEPCIONAL O AMBIGUO: use un reemplazo adecuado o reconstruya un pool nuevo correctamente alineado en lugar de forzar un disco de menor capacidad. Conserve los registros y no ejecute comandos de reparación, depuración, destrucción, reparticionado o cambio recursivo de propietario hasta que exista una copia recuperable.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirme la decisión con la carga de trabajo original

Aplique la acción correspondiente a la rama observada y después repita la condición original en lugar de un sustituto reducido. La decisión solo se mantiene cuando el reemplazo se conecta, la resilverización se completa y la latencia de las escrituras alineadas sigue siendo aceptable durante dos ciclos o durante el reinicio, suspensión, interrupción o transición de carga pertinente.

Use los tamaños de sector del espejo ZFS para comprobar el flujo de trabajo dependiente más cercano, pero mantenga sin cambios el desencadenante original. Los conjuntos de datos, recursos compartidos, contenedores, usuarios y puntos de recuperación no relacionados deben conservar su acceso y sus tiempos anteriores.

El límite de detención es explícito: si el ashift es demasiado pequeño, el reemplazo es ligeramente más pequeño o el rendimiento se degrada con escrituras síncronas y aleatorias, vuelva a la última configuración verificada, conserve la evidencia y escale a una prueba más profunda de la plataforma o del hardware solo cuando la rama pueda reproducirse.

Después de que se mantenga el resultado objetivo, compárelo con la verificación de restauración para que la corrección no traslade el riesgo a un servicio vecino. Una prueba objetivo superada con un nuevo fallo de copia de seguridad, identidad, tiempo de espera o disponibilidad sigue siendo un cambio fallido.

Preguntas frecuentes

En un espejo ZFS con sectores mixtos, las búsquedas restantes suelen referirse a si se puede cambiar ashift después de crear el vdev, si debe usarse ashift=12 para discos de 4K y si importa una capacidad diferente. Las respuestas siguientes mantienen esos casos límite separados de la decisión principal.

El límite de aceptación no cambia: el reemplazo se conecta, la resilverización se completa y la latencia de las escrituras alineadas sigue siendo aceptable. Si una condición posterior cambia el sistema de archivos, la identidad, la ruta de red o la versión de la aplicación, repita únicamente el discriminador afectado por ese cambio.

Deje de ampliar el experimento cuando el ashift sea demasiado pequeño, el reemplazo sea ligeramente más pequeño o el rendimiento se degrade con escrituras síncronas y aleatorias. En ese punto, use un reemplazo adecuado o reconstruya un pool nuevo correctamente alineado en lugar de forzar un disco de menor capacidad; conserve la evidencia antes de escalar al responsable de la plataforma, del almacenamiento o del hardware.

¿Se puede cambiar ashift después de crear el vdev?

No directamente en un vdev existente; lo habitual es reconstruirlo o crear un vdev nuevo.

¿Debe usarse ashift=12 para discos de 4K?

Habitualmente representa una alineación de 4K, pero valide el comportamiento del dispositivo y las indicaciones actuales de OpenZFS.

¿Importa una capacidad diferente?

Un espejo está limitado por su miembro más pequeño, y un reemplazo nominal puede ser ligeramente más pequeño.

En un espejo ZFS con sectores mixtos, la respuesta práctica sigue siendo condicional: el reemplazo se conecta, la resilverización se completa y la latencia de las escrituras alineadas sigue siendo aceptable. Cuando el ashift es demasiado pequeño, el reemplazo es ligeramente más pequeño o el rendimiento se degrada con escrituras síncronas y aleatorias, use un reemplazo adecuado o reconstruya un pool nuevo correctamente alineado en lugar de forzar un disco de menor capacidad; un éxito parcial que no puede soportar la carga de trabajo original no es compatibilidad.