Btrfs

Btrfs proporciona una operación de clonación que crea atómicamente una instantánea de copia en escritura de un archivo . Estos archivos clonados a veces se denominan reflinks , en vista de la llamada al sistema del kernel de Linux asociada propuesta . ^{[ 56 ]}

Al clonar, el sistema de archivos no crea un nuevo enlace que apunte a un inodo existente ; en su lugar, crea un nuevo inodo que inicialmente comparte los mismos bloques de disco con el archivo original. Como resultado, la clonación solo funciona dentro de los límites del mismo sistema de archivos Btrfs, pero desde la versión 3.6 del kernel de Linux puede cruzar los límites de los subvolúmenes en ciertas circunstancias. ^{[ 57 ] [ 58 ]} Los bloques de datos reales no se duplican; al mismo tiempo, debido a la naturaleza de copia en escritura (CoW) de Btrfs, las modificaciones en cualquiera de los archivos clonados no son visibles en el archivo original y viceversa. ^{[ 59 ]}

La clonación no debe confundirse con los enlaces duros , que son entradas de directorio que asocian varios nombres de archivo a un solo archivo. Si bien los enlaces duros pueden interpretarse como nombres diferentes para el mismo archivo, la clonación en Btrfs proporciona archivos independientes que inicialmente comparten todos sus bloques de disco. ^{[ 59 ] [ 60 ]}

La compatibilidad con esta característica de Btrfs se agregó en la versión 7.5 de GNU coreutils , a través de la --reflinkopción del cpcomando. ^{[ 61 ] [ 62 ]}

Además de la clonación de datos ( FICLONE ), Btrfs también admite la deduplicación fuera de banda mediante FIDEDUPERANGE . Esta funcionalidad permite que dos archivos con datos (incluso parcialmente) idénticos compartan almacenamiento. ^{[ 63 ] [ 9 ]}

Un subvolumen Btrfs puede considerarse como un espacio de nombres de archivos POSIX independiente , que se puede montar por separado pasando subvolopciones subvolida la mount(8)utilidad. También se puede acceder a él montando el subvolumen de nivel superior, en cuyo caso los subvolúmenes son visibles y accesibles como sus subdirectorios. ^{[ 64 ]}

Los subvolúmenes se pueden crear en cualquier lugar de la jerarquía del sistema de archivos y también se pueden anidar. Los subvolúmenes anidados aparecen como subdirectorios dentro de sus subvolúmenes principales, de forma similar a como un subvolumen de nivel superior presenta sus subvolúmenes como subdirectorios. No es posible eliminar un subvolumen hasta que se hayan eliminado todos los subvolúmenes que se encuentran debajo de él en la jerarquía de anidamiento; por lo tanto, los subvolúmenes de nivel superior no se pueden eliminar. ^{[ 65 ]}

Cualquier sistema de archivos Btrfs siempre tiene un subvolumen predeterminado, que inicialmente se establece como el subvolumen de nivel superior y se monta por defecto si no se pasa ninguna opción de selección de subvolumen a mount. El subvolumen predeterminado se puede cambiar según sea necesario. ^{[ 65 ]}

Una instantánea de Btrfs es un subvolumen que comparte sus datos (y metadatos) con otro subvolumen, utilizando las capacidades de copia en escritura de Btrfs. Las modificaciones realizadas a una instantánea no son visibles en el subvolumen original. Una vez creada una instantánea editable, puede tratarse como una versión alternativa del sistema de archivos original. Por ejemplo, para revertir a una instantánea, es necesario desmontar el subvolumen original modificado y montar la instantánea en su lugar. En ese momento, también se puede eliminar el subvolumen original. ^{[ 64 ]}

La naturaleza de copia en escritura (CoW) de Btrfs implica que las instantáneas se crean rápidamente, consumiendo inicialmente muy poco espacio en disco. Dado que una instantánea es un subvolumen, también es posible crear instantáneas anidadas. La creación de instantáneas de un subvolumen no es un proceso recursivo; por lo tanto, si se crea una instantánea de un subvolumen, cada subvolumen o instantánea que este ya contiene se asigna a un directorio vacío con el mismo nombre dentro de la instantánea. ^{[ 64 ] [ 65 ]}

No es posible crear instantáneas de un directorio, ya que solo los subvolúmenes pueden tenerlas. Sin embargo, existe una solución alternativa que implica enlaces de referencia distribuidos entre subvolúmenes: se crea un nuevo subvolumen que contiene enlaces de referencia entre subvolúmenes al contenido del directorio de destino. Una vez disponible, se puede crear una instantánea de este nuevo volumen. ^{[ 57 ]}

Un subvolumen en Btrfs es bastante diferente de un volumen lógico tradicional del Administrador de Volúmenes Lógicos (LVM). Con LVM, un volumen lógico es un dispositivo de bloques independiente , mientras que un subvolumen de Btrfs no lo es y no puede tratarse ni utilizarse de esa manera. ^{[ 64 ]} La creación de instantáneas de btrfs mediante dd o LVM conlleva la pérdida de datos si el original o la copia se montan mientras ambos se encuentran en el mismo equipo. ^{[ 66 ]}

Dado cualquier par de subvolúmenes (o instantáneas), Btrfs puede generar una diferencia binaria entre ellos (mediante el btrfs sendcomando) que puede reproducirse posteriormente (mediante btrfs receive), posiblemente en un sistema de archivos Btrfs diferente. La función de envío-recepción crea (y aplica) un conjunto de modificaciones de datos necesarias para convertir un subvolumen en otro. ^{[ 50 ] [ 67 ]}

La función de envío/recepción se puede utilizar con instantáneas programadas regularmente para implementar una forma simple de replicación del sistema de archivos , o con el propósito de realizar copias de seguridad incrementales . ^{[ 50 ] [ 67 ]}

Un grupo de cuotas (o qgroup ) impone un límite superior al espacio que puede consumir un subvolumen o una instantánea. Inicialmente, una nueva instantánea no consume cuota porque sus datos se comparten con su elemento principal, pero posteriormente se le cobra por los archivos nuevos y las operaciones de copia en escritura en los archivos existentes. Cuando las cuotas están activas, se crea automáticamente un grupo de cuotas con cada nuevo subvolumen o instantánea. Estos grupos de cuotas iniciales son bloques de construcción que se pueden agrupar (con el btrfs qgroupcomando) en jerarquías para implementar grupos de cuotas. ^{[ 52 ]}

Los grupos de cuotas solo se aplican a subvolúmenes e instantáneas, y no es posible aplicar cuotas a subdirectorios, usuarios o grupos de usuarios individuales. Sin embargo, existen soluciones alternativas que consisten en utilizar subvolúmenes diferentes para todos los usuarios o grupos de usuarios que requieran la aplicación de una cuota.

Como resultado de tener muy pocos metadatos anclados en ubicaciones fijas, Btrfs puede adaptarse a diseños espaciales inusuales de los dispositivos de almacenamiento de backend. La btrfs-convertherramienta aprovecha esta capacidad para realizar una conversión in situ de un sistema de archivos ext2/3/4 o ReiserFS , anidando los metadatos Btrfs equivalentes en su espacio no asignado, al tiempo que conserva una copia sin modificar del sistema de archivos original. ^{[ 68 ]}

La conversión implica la creación de una copia de todos los metadatos de ext2/3/4, mientras que los archivos Btrfs simplemente apuntan a los mismos bloques utilizados por los archivos ext2/3/4. Esto hace que la mayor parte de los bloques se compartan entre los dos sistemas de archivos antes de que la conversión sea permanente. Gracias a la naturaleza de copia en escritura de Btrfs, las versiones originales de los bloques de datos de los archivos se conservan durante todas las modificaciones de archivos. Hasta que la conversión sea permanente, solo los bloques que se marcaron como libres en ext2/3/4 se utilizan para almacenar las nuevas modificaciones de Btrfs, lo que significa que la conversión se puede deshacer en cualquier momento (aunque al hacerlo se borrarán todos los cambios realizados después de la conversión a Btrfs). ^{[ 68 ]}

Todos los archivos convertidos están disponibles y son escribibles en el subvolumen predeterminado de Btrfs. Se crea un archivo disperso que contiene todas las referencias al sistema de archivos ext2/3/4 original en un subvolumen separado, el cual se puede montar de forma independiente como una imagen de disco de solo lectura, lo que permite acceder simultáneamente a los sistemas de archivos original y convertido. Al eliminar este archivo disperso, se libera el espacio y la conversión se vuelve permanente. ^{[ 68 ]}

En las versiones 4.x del kernel principal de Linux, la conversión in situ de ext3/4 se consideraba no probada y rara vez se utilizaba. ^{[ 68 ]} Sin embargo, la característica se reescribió desde cero en 2016 para la btrfs-progsversión 4.6. ^{[ 48 ]} y se ha considerado estable desde entonces.

La conversión in situ desde ReiserFS se introdujo en septiembre de 2017 con el kernel 4.13. ^{[ 69 ]}

Al crear un nuevo Btrfs, se puede usar un Btrfs existente como un sistema de archivos "semilla" de solo lectura. ^{[ 70 ]} El nuevo sistema de archivos actuará entonces como una superposición de copia en escritura sobre la semilla, como una forma de montaje de unión . La semilla se puede desvincular posteriormente del Btrfs, momento en el que el reequilibrador simplemente copiará cualquier dato de semilla que aún sea referenciado por el nuevo sistema de archivos antes de desvincularse. Mason ha sugerido que esto puede ser útil para un instalador de Live CD , que podría arrancar desde una semilla Btrfs de solo lectura en un disco óptico, reequilibrarse a sí mismo a la partición de destino en el disco de instalación en segundo plano mientras el usuario continúa trabajando, y luego expulsar el disco para completar la instalación sin reiniciar.

En su entrevista de 2009, Mason afirmó que se planeaba brindar soporte para cifrado en Btrfs. ^{[ 8 ]} Mientras tanto, una solución alternativa para combinar el cifrado con Btrfs consiste en utilizar un mecanismo de cifrado de disco completo como dm-crypt  / LUKS en los dispositivos subyacentes y crear el sistema de archivos Btrfs sobre esa capa.

A partir de 2020,Los desarrolladores estaban trabajando para agregar un hash con clave como HMAC ( SHA256 ). ^{[ 71 ]}

Los sistemas Unix tradicionalmente dependen de los programas " fsck " para verificar y reparar los sistemas de archivos. Esta funcionalidad se implementa a través del btrfs checkprograma. Desde la versión 4.0, esta funcionalidad se considera relativamente estable. Sin embargo, a partir de diciembre de 2022 ,La documentación de btrfs sugiere que su --repairopción se utilice únicamente si se ha recibido asesoramiento de "un desarrollador o un usuario experimentado". ^{[ 39 ]} A partir de agosto de 2022 ,La documentación de SLE recomienda usar un Live CD, realizar una copia de seguridad y usar la opción de reparación solo como último recurso. ^{[ 72 ]}

Existe otra herramienta, denominada btrfs-restore, que puede utilizarse para recuperar archivos de un sistema de archivos inaccesible, sin modificar el propio sistema de archivos dañado (es decir, de forma no destructiva). ^{[ 73 ] [ 74 ]}

En condiciones normales de uso, Btrfs se autorrepara en gran medida y puede recuperarse de árboles raíz dañados durante el montaje, gracias a que realiza vaciados periódicos de datos al almacenamiento permanente, por defecto cada 30 segundos. Por lo tanto, los errores aislados provocarán la pérdida de un máximo de 30 segundos de cambios en el sistema de archivos en el siguiente montaje. ^{[ 75 ]} Este período se puede modificar especificando un valor deseado (en segundos) con la commitopción de montaje. ^{[ 76 ] [ 77 ]}

Dentro de cada directorio, las entradas de directorio aparecen como elementos de directorio , cuyos bits menos significativos de los valores de clave son un hash CRC32C de su nombre de archivo. Sus datos son una clave de ubicación , o la clave del elemento de inodo al que apunta. Los elementos de directorio juntos pueden actuar como un índice para búsquedas de ruta a inodo, pero no se utilizan para iteración porque están ordenados por su hash, lo que efectivamente los permuta aleatoriamente . Esto significa que las aplicaciones de usuario que iteran sobre y abren archivos en un directorio grande generarían muchas más búsquedas de disco entre archivos no adyacentes, una notable pérdida de rendimiento en otros sistemas de archivos con directorios ordenados por hash como ReiserFS , ^{[ 79 ]} ext3 (con índices Htree habilitados ^{[ 80 ]} ) y ext4, todos los cuales tienen nombres de archivo con hash TEA . Para evitar esto, cada entrada de directorio tiene un elemento de índice de directorio , cuyo valor de clave del elemento se establece en un contador por directorio que se incrementa con cada nueva entrada de directorio. Por lo tanto, al iterar sobre estos elementos del índice, se devuelven las entradas aproximadamente en el mismo orden en que están almacenadas en el disco.

Los archivos con enlaces duros en varios directorios tienen múltiples elementos de referencia, uno para cada directorio padre. Los archivos con múltiples enlaces duros en el mismo directorio empaquetan todos los nombres de archivo de los enlaces en el mismo elemento de referencia. Esto fue un fallo de diseño que limitaba el número de enlaces duros del mismo directorio a la cantidad que cabía en un solo bloque de árbol. (Con un tamaño de bloque predeterminado de 4  KiB, una longitud promedio de nombre de archivo de 8 bytes y un encabezado por nombre de archivo de 4 bytes, esto sería menos de 350). Se observó que las aplicaciones que hacían un uso intensivo de múltiples enlaces duros del mismo directorio, como git , GNUS , GMame y BackupPC , fallaban al alcanzar este límite. ^{[ 81 ]} El límite finalmente se eliminó ^{[ 82 ]} (y a partir de octubre de 2012 Se ha fusionado ^{[ 83 ]} pendiente de lanzamiento en Linux 3.7) mediante la introducción de elementos de referencia extendida de desbordamiento para contener nombres de archivos de enlace duro que de otro modo no encajarían.

El árbol de asignación de extensiones actúa como un mapa de asignación para el sistema de archivos. A diferencia de otros árboles, los elementos de este árbol no tienen identificadores de objeto. Representan regiones del espacio: sus claves contienen los desplazamientos iniciales y las longitudes de las regiones que representan.

El sistema de archivos divide su espacio asignado en grupos de bloques , que son regiones de asignación de tamaño variable que alternan entre dar preferencia a las extensiones de metadatos (nodos del árbol) y a las extensiones de datos (contenido de los archivos). La proporción predeterminada de grupos de bloques de datos a metadatos es de 1:2. Su propósito es utilizar conceptos del asignador de bloques Orlov para asignar archivos relacionados juntos y resistir la fragmentación dejando espacio libre entre grupos. (Sin embargo, los grupos de bloques de Ext3 tienen ubicaciones fijas calculadas a partir del tamaño del sistema de archivos, mientras que los de Btrfs son dinámicos y se crean según sea necesario). Cada grupo de bloques está asociado con un elemento de grupo de bloques . Los elementos de inodo en el árbol del sistema de archivos incluyen una referencia a su grupo de bloques actual. ^{[ 4 ]}

Los elementos de extensión contienen una referencia inversa al nodo de árbol o archivo que ocupa dicha extensión. Puede haber varias referencias inversas si la extensión se comparte entre instantáneas. Si hay demasiadas referencias inversas para que quepan en el elemento, se desbordan a elementos de referencia de datos de extensión individuales . Los nodos de árbol, a su vez, tienen referencias inversas a los árboles que los contienen. Esto permite encontrar qué extensiones o nodos de árbol se encuentran en cualquier región del espacio mediante una búsqueda de rango de árbol B en un par de desplazamientos que delimitan esa región, y luego siguiendo las referencias inversas. Para reubicar datos, esto permite un recorrido ascendente eficiente desde los bloques reubicados para encontrar y corregir rápidamente todas las referencias descendentes a esos bloques, sin tener que escanear todo el sistema de archivos. Esto, a su vez, permite que el sistema de archivos reduzca, migre y desfragmente su almacenamiento en línea de manera eficiente.

El árbol de asignación de extensiones, al igual que todos los demás árboles del sistema de archivos, utiliza la técnica de copia en escritura. Por lo tanto, las escrituras en el sistema de archivos pueden provocar una cascada en la que los cambios en los nodos del árbol y en los datos de los archivos dan lugar a la asignación de nuevas extensiones, lo que a su vez modifica el propio árbol de extensiones. Para evitar un bucle de retroalimentación , los nodos del árbol de extensiones que aún se encuentran en memoria pero que todavía no se han guardado en el disco pueden actualizarse in situ para reflejar las nuevas extensiones copiadas en escritura.

En teoría, el árbol de asignación de extensiones hace innecesario un mapa de bits de espacio libre convencional porque actúa como una versión de árbol B de un árbol BSP . Sin embargo, en la práctica, se utiliza un árbol rojo-negro en memoria de mapas de bits del tamaño de una página para acelerar las asignaciones. Estos mapas de bits se almacenan en disco (a partir de Linux 2.6.37, mediante la space_cacheopción de montaje ^{[ 84 ]} ) como extensiones especiales que están exentas de la verificación de suma de comprobación y la copia en escritura.

Las sumas de verificación CRC-32C se calculan tanto para los datos como para los metadatos y se almacenan como elementos de suma de verificación en un árbol de sumas de verificación . Hay espacio para 256  bits de sumas de verificación de metadatos y hasta un nodo completo (aproximadamente 4  KB o más) para sumas de verificación de datos. Btrfs contempla la posibilidad de añadir algoritmos de suma de verificación adicionales en futuras versiones del sistema de archivos. ^{[ 36 ] [ 85 ]}

Hay un elemento de suma de verificación por cada secuencia contigua de bloques asignados, con las sumas de verificación de cada bloque empaquetadas de extremo a extremo en los datos del elemento. Si hay más sumas de verificación de las que caben, se desbordan a otro elemento de suma de verificación en una nueva hoja. Si el sistema de archivos detecta una discrepancia en la suma de verificación al leer un bloque, primero intenta obtener (o crear) una copia correcta de este bloque desde otro dispositivo , si se utilizan técnicas de duplicación interna o RAID. ^{[ 86 ] [ 87 ]} 

Btrfs puede iniciar una comprobación en línea de todo el sistema de archivos activando una tarea de limpieza del sistema de archivos que se ejecuta en segundo plano. La tarea de limpieza escanea todo el sistema de archivos para comprobar su integridad e intenta automáticamente informar y reparar cualquier bloque defectuoso que encuentre. ^{[ 86 ] [ 88 ]}

Una solicitud fsync confirma los datos modificados inmediatamente en el almacenamiento permanente. Las cargas de trabajo intensivas en fsync (como una base de datos o una máquina virtual que ejecuta fsyncs del sistema operativo con frecuencia) podrían generar una gran cantidad de E/S de escritura redundante al obligar al sistema de archivos a copiar repetidamente en escritura y volcar las partes de los árboles que se modifican con frecuencia al almacenamiento. Para evitar esto, se crea un árbol de registro temporal por subvolumen para registrar las copias activadas por fsync en escritura. Los árboles de registro son autónomos, rastrean sus propias extensiones y mantienen sus propios elementos de suma de verificación. Sus elementos se reproducen y se eliminan en la siguiente confirmación completa del árbol o (si hubo un fallo del sistema) en el siguiente remontaje.

Los dispositivos de bloques se dividen en fragmentos físicos de 1  GiB para datos y 256  MiB para metadatos. ^{[ 89 ]} Los fragmentos físicos distribuidos en varios dispositivos pueden replicarse o combinarse en un único fragmento lógico . Estos fragmentos lógicos se combinan en un único espacio de direcciones lógicas que utiliza el resto del sistema de archivos.

El árbol de fragmentos realiza un seguimiento de esto almacenando cada dispositivo como un elemento de dispositivo y los fragmentos lógicos como elementos de mapa de fragmentos , que proporcionan una asignación directa de direcciones lógicas a físicas almacenando sus desplazamientos en los 64 bits menos significativos de su clave. Los elementos de mapa de fragmentos pueden ser de varios tipos diferentes:

soltero

1 fragmento lógico a 1 fragmento físico

duplicado

1 bloque lógico a 2 bloques físicos en 1 dispositivo de bloques

raid0

N bloques lógicos a N≥2 bloques físicos a través de N≥2 dispositivos de bloques

raid1

1 bloque lógico a 2 bloques físicos en 2 de N≥2 dispositivos de bloques, ^{[ 90 ]} en contraste con RAID 1 convencional que tiene N bloques físicos

raid1c3

1 bloque lógico a 3 bloques físicos de N≥3 dispositivos de bloques

raid1c4

1 bloque lógico a 4 bloques físicos de N≥4 dispositivos de bloques

raid5

N (para N≥2) bloques lógicos a N+1 bloques físicos en N+1 dispositivos de bloques, con 1 bloque físico utilizado como paridad.

raid6

N (para N≥2) bloques lógicos a N+2 bloques físicos en N+2 dispositivos de bloques, con 2 bloques físicos utilizados como paridad.

N es el número de dispositivos de bloques que aún tienen espacio libre cuando se asigna el fragmento. Si N no es lo suficientemente grande para la duplicación/mapeo elegido, entonces el sistema de archivos se queda sin espacio.

Las operaciones de desfragmentación, reducción y reequilibrio requieren la reubicación de extensiones. Sin embargo, realizar una simple copia en escritura de la extensión que se va a reubicar interrumpirá el uso compartido entre instantáneas y consumirá espacio en disco. Para preservar el uso compartido, se utiliza un algoritmo de actualización e intercambio, con un árbol de reubicación especial que sirve como espacio temporal para los metadatos afectados. La extensión que se va a reubicar se copia primero a su destino. Luego, siguiendo las referencias inversas hacia arriba a través del árbol del sistema de archivos del subvolumen afectado, los metadatos que apuntan a la extensión antigua se actualizan progresivamente para que apunten a la nueva; cualquier elemento recién actualizado se almacena en el árbol de reubicación. Una vez completada la actualización, los elementos del árbol de reubicación se intercambian con sus contrapartes en el subvolumen afectado y el árbol de reubicación se descarta. ^{[ 91 ]}

Todos los árboles del sistema de archivos, incluido el propio árbol de fragmentos, se almacenan en fragmentos, lo que crea un posible problema de arranque al montar el sistema de archivos. Para arrancar en un montaje, se almacena en el superbloque una lista de direcciones físicas de los fragmentos que pertenecen a los árboles de fragmentos y raíz . ^{[ 92 ]}

Los espejos de superbloque se mantienen en ubicaciones fijas: ^{[ 93 ]} 64 KiB en cada dispositivo de bloque, con copias adicionales en 64 MiB, 256 GiB y 1 PiB. Cuando se actualiza un espejo de superbloque, se incrementa su número de generación . En el momento del montaje, se utiliza la copia con el número de generación más alto. Todos los espejos de superbloque se actualizan en tándem, excepto en el modo SSD que alterna las actualizaciones entre los espejos para proporcionar cierta nivelación de desgaste .

• Oracle Linux desde la versión 7 ^{[ 94 ]}
• SUSE Linux Enterprise Server desde la versión 12 ^{[ 95 ] [ 96 ]}
• Synology DiskStation Manager (DSM) de la versión 6.0 ^{[ 97 ]}
• Fedora Workstation desde la versión 33 ^{[ 35 ]}
• AlmaLinux desde la versión 10.1 ^{[ 98 ]}
• Asustor , desde ADM 3.3 ^{[ 99 ]}
• TerraMaster , desde TOS 4.1 ^{[ 100 ]}

• Btrfs se incluyó como una "vista previa tecnológica" en Red Hat Enterprise Linux 6 y 7; ^{[ 23 ] [ 32 ]} se eliminó en RHEL 8 en 2018. ^{[ 33 ] [ 101 ] [ 102 ]}