¿BTRFS garantiza la consistencia de los datos en cortes de energía?

Como ZFS declara exclusivamente ,Se afirma que ZFS es invulnerable ZFS acepta que podría ser vulnerable a fallas de energía.

No pude encontrar tal declaración para BTRFS. ¿Es (o diseñado / planeado para ser) duradero entre cortes de energía?

Hice la pregunta en #btrfs IRC, dijeron should be ok if your hw isn't "buggy"donde no significa "buggy" your hw has correct flush/barrier semantics.

TL; DR: Esto significa que btrfs está protegido contra la corrupción de datos debido a la pérdida de energía de manera similar a ZFS.

Aquí está la razón: la idea general detrás de ZFS y btrfs es similar. Ambos usan árboles de Merkle como estructura de datos . Las escrituras pueden requerir que se actualicen varios bloques en los discos. El sistema de archivos está manejando esto escribiendo los datos nuevos en bloques vacíos (incluso si se está modificando un archivo existente, por lo tanto, no necesita modificar bloques que reflejen el estado anterior) y construyendo un nuevo árbol actualizado. Una vez que se realiza todo el trabajo pesado y los datos + el árbol actualizado se han escrito en el disco, el puntero de la cabeza se actualiza al nuevo árbol haciendo visible el cambio.

Así es como se supone que deben comportarse las cosas al escribir en un archivo:

1. Escriba datos en bloques libres en el disco.
2. Haga una copia del árbol Merkle *, actualícelo de acuerdo con los cambios escritos en (1).
3. Solicite al hardware que vacíe los datos en el disco: el hardware escribe todos los datos pendientes.
4. Actualice el puntero de la cabeza al nuevo árbol Merkle.
5. Bloques viejos gratis que ya no son necesarios.

Si se pierde energía después de (4) la transacción se ha completado. Si se pierde energía durante los pasos (1) a (3), el sistema de archivos mostrará el estado anterior (los datos escritos en el paso (1) se pierden pero el sistema de archivos es coherente). Tenga en cuenta que no es necesario verificar si hay errores en el sistema de archivos, lo que significa que el sistema de archivos está disponible de inmediato, lo cual es una gran ventaja (¡verificar sistemas de archivos grandes puede llevar mucho tiempo!).

Aquí hay un ejemplo de cómo las cosas pueden salir mal con el hardware "defectuoso":

1. Escriba datos en bloques libres en el disco.
2. Haga una copia del árbol Merkle *, actualícelo de acuerdo con los cambios escritos en (1).
3. Solicite al hardware que vacíe los datos en el disco: el hardware confirma que se completó pero no se vacía por completo (por ejemplo, los datos pueden permanecer en la caché de reescritura del disco).
4. Actualice el puntero de la cabeza al nuevo árbol Merkle. Estos datos se escriben en el disco antes que otros datos pendientes (por ejemplo, porque la cabeza del disco está en la ubicación correcta).
5. Los datos escritos en los pasos (1) y (2) se escriben en el disco.
6. Bloques viejos gratis que ya no son necesarios.

El sistema de archivos se volverá inconsistente si se pierde energía entre (4) y (5) o mientras se realiza el paso (5). Como consecuencia, el árbol de Merkle y / o los datos solo pueden escribirse parcialmente, lo que hace que el sistema de archivos se vuelva inconsistente.

En la práctica, debe tener especial cuidado al utilizar controladores RAID . Por lo general, deshabilitan las memorias caché de reescritura en el disco y utilizan su propia memoria caché de reescritura. Hay dos formas comunes de que las cosas salgan mal aquí:

• El caché del controlador RAID es RAM. Si no está respaldado por una batería o alguna tecnología similar, puede perder una cantidad significativa de datos.
• Algunos discos no deshabilitan sus cachés de reescritura cuando se les pide que lo hagan . Es más probable que esto suceda con unidades de escritorio baratas que con unidades de servidor diseñadas para RAID.

* Estoy simplificando las cosas aquí. En realidad no es necesario copiar todo el árbol. Solo se deben agregar las partes que cambiaron; las partes restantes se pueden compartir entre el árbol antiguo y el nuevo .