Btrfs (pronunciado como "better F S", [9] "butter F S", [13] [14] "b-tree F S", [14] o BTRFS) es un formato de almacenamiento informático que combina un sistema de archivos basado en el principio de copia en escritura (COW) con un administrador de volúmenes lógicos (distinto del LVM de Linux ), desarrollado en conjunto. Fue creado por Chris Mason en 2007 [15] para su uso en Linux , y desde noviembre de 2013, el formato en disco del sistema de archivos ha sido declarado estable en el núcleo de Linux . [16]
Btrfs tiene como objetivo abordar la falta de agrupación , instantáneas , sumas de comprobación y expansión integral de múltiples dispositivos en los sistemas de archivos Linux . [9] Mason, el autor principal de Btrfs, afirmó que su objetivo era "permitir que [Linux] escale para el almacenamiento que estará disponible. El escalamiento no se trata solo de abordar el almacenamiento, sino que también significa poder administrarlo y gestionarlo con una interfaz limpia que permita a las personas ver qué se está utilizando y lo haga más confiable". [17]
La estructura de datos principal de Btrfs (el árbol B de copia en escritura ) fue propuesta originalmente por el investigador de IBM Ohad Rodeh en una conferencia de USENIX en 2007. [18] Mason, un ingeniero que trabajaba en ReiserFS para SUSE en ese momento, se unió a Oracle más tarde ese año y comenzó a trabajar en un nuevo sistema de archivos basado en estos árboles B. [19]
En 2008, el principal desarrollador de los sistemas de archivos ext3 y ext4 , Theodore Ts'o , afirmó que, aunque ext4 ha mejorado sus características, no es un gran avance; utiliza tecnología antigua y es una solución provisional. Ts'o dijo que Btrfs es la mejor dirección porque "ofrece mejoras en escalabilidad, confiabilidad y facilidad de administración". [20] Btrfs también tiene "varias de las mismas ideas de diseño que reiser3 / 4 ". [21]
Btrfs 1.0, con un formato finalizado en disco, fue originalmente programado para un lanzamiento a fines de 2008, [22] y finalmente fue aceptado en la línea principal del kernel de Linux en 2009. [23] Varias distribuciones de Linux comenzaron a ofrecer Btrfs como una opción experimental de sistema de archivos raíz durante la instalación. [24] [25] [26]
En julio de 2011, las características de desfragmentación y limpieza automáticas de Btrfs se fusionaron en la versión 3.0 de la línea principal del kernel de Linux . [27] Además de Mason en Oracle, Miao Xie en Fujitsu contribuyó con mejoras de rendimiento. [28] En junio de 2012, Mason dejó Oracle para Fusion-io , que abandonó un año después con Josef Bacik para unirse a Facebook . Mientras estuvo en ambas empresas, Mason continuó su trabajo en Btrfs. [29] [19]
En 2012, dos distribuciones de Linux trasladaron Btrfs del estado experimental al de producción o soporte: Oracle Linux en marzo, [30] seguido por SUSE Linux Enterprise en agosto. [31]
En 2015, Btrfs se adoptó como el sistema de archivos predeterminado para SUSE Linux Enterprise Server (SLE) 12. [32]
En agosto de 2017, Red Hat anunció en las notas de la versión de Red Hat Enterprise Linux (RHEL) 7.4 que ya no planeaba mover Btrfs a una característica totalmente compatible (se ha incluido como una "vista previa de tecnología" desde la versión beta de RHEL 6) y señaló que permanecería disponible en la serie de lanzamientos de RHEL 7. [33] Btrfs se eliminó de RHEL 8 en mayo de 2019. [34] RHEL pasó de ext4 en RHEL 6 a XFS en RHEL 7. [35]
En 2020, Btrfs fue seleccionado como el sistema de archivos predeterminado para Fedora 33 para las variantes de escritorio. [36]
A partir de la versión 5.0 del kernel de Linux, Btrfs implementa las siguientes características: [37] [38]
cp --reflink <source file> <destination file>[44]Btrfs proporciona una operación de clonación que crea de forma atómica una instantánea de copia en escritura de un archivo . A estos archivos clonados a veces se los denomina "reflinks" , en vista de la llamada al sistema del núcleo de Linux asociada propuesta . [55]
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 funciona solo 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 determinadas circunstancias. [56] [57] Los bloques de datos reales no se duplican; al mismo tiempo, debido a la naturaleza de copia en escritura (CoW) de Btrfs, las modificaciones a cualquiera de los archivos clonados no son visibles en el archivo original y viceversa. [58]
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 tomarse como nombres diferentes para el mismo archivo, la clonación en Btrfs proporciona archivos independientes que inicialmente comparten todos sus bloques de disco. [58] [59]
El soporte para 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. [60] [61]
Además de la clonación de datos ( FICLONE ), Btrfs también admite la deduplicación fuera de banda a través de FIDEDUPERANGE . Esta funcionalidad permite que dos archivos con datos (incluso parcialmente) idénticos compartan el almacenamiento. [62] [10]
Un subvolumen Btrfs puede considerarse como un espacio de nombres de archivo POSIX independiente , que se puede montar por separado al pasarle opciones subvolo a la 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. [63]subvolid
Los subvolúmenes se pueden crear en cualquier lugar dentro 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 manera similar a la forma en que un subvolúmen de nivel superior presenta sus subvolúmenes como subdirectorios. No es posible eliminar un subvolúmen hasta que se eliminen todos los subvolúmenes que se encuentran debajo de él en la jerarquía de anidamiento; como resultado, los subvolúmenes de nivel superior no se pueden eliminar. [64]
Cualquier sistema de archivos Btrfs siempre tiene un subvolumen predeterminado, que inicialmente se configura como el subvolumen de nivel superior y se monta de manera predeterminada si no se pasa ninguna opción de selección de subvolumen a mount. El subvolumen predeterminado se puede cambiar según sea necesario. [64]
Una instantánea de Btrfs es un subvolumen que comparte sus datos (y metadatos) con algún otro subvolumen, utilizando las capacidades de copia en escritura de Btrfs, y las modificaciones a una instantánea no son visibles en el subvolumen original. Una vez que se crea una instantánea escribible, se puede tratar como una versión alternativa del sistema de archivos original. Por ejemplo, para volver a una instantánea, se debe desmontar un subvolumen original modificado y se debe montar la instantánea en su lugar. En ese punto, también se puede eliminar el subvolumen original. [63]
La naturaleza de copia en escritura (CoW) de Btrfs significa que las instantáneas se crean rápidamente, mientras que inicialmente consumen muy poco espacio en disco. Dado que una instantánea es un subvolumen, también es posible crear instantáneas anidadas. Tomar 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 el subvolumen ya contiene se asigna a un directorio vacío del mismo nombre dentro de la instantánea. [63] [64]
No es posible tomar instantáneas de un directorio, ya que solo los subvolúmenes pueden tener instantáneas. Sin embargo, existe una solución alternativa que implica enlaces de referencia distribuidos en subvolúmenes: se crea un nuevo subvolumen, que contiene enlaces de referencia entre subvolúmenes al contenido del directorio de destino. Si se dispone de eso, se puede crear una instantánea de este nuevo volumen. [56]
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 bloque independiente , mientras que un subvolumen de Btrfs no lo es y no se lo puede tratar ni utilizar de esa manera. [63] Hacer instantáneas de btrfs en dd o LVM conduce a la pérdida de datos si se monta el original o la copia mientras ambos están en la misma computadora. [65]
Dado cualquier par de subvolúmenes (o instantáneas), Btrfs puede generar una diferencia binaria entre ellos (mediante el uso del btrfs sendcomando ) que se puede reproducir más tarde (mediante el uso de btrfs receive), posiblemente en un sistema de archivos Btrfs diferente. La función de envío y recepción crea (y aplica) de manera efectiva un conjunto de modificaciones de datos necesarias para convertir un subvolumen en otro. [49] [66]
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 . [49] [66]
Un grupo de cuotas (o qgroup ) impone un límite superior al espacio que puede consumir un subvolumen o una instantánea. Una nueva instantánea no consume cuota inicialmente porque sus datos se comparten con su padre, pero a partir de entonces se genera un cargo 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. [51]
Los grupos de cuotas solo se aplican a subvolúmenes e instantáneas, mientras que no es posible aplicar cuotas a subdirectorios, usuarios o grupos de usuarios individuales. Sin embargo, existen soluciones alternativas mediante el uso de subvolúmenes diferentes para todos los usuarios o grupos de usuarios que requieren que se aplique una cuota.
Como resultado de tener muy pocos metadatos anclados en ubicaciones fijas, Btrfs puede deformarse para adaptarse a diseños espaciales inusuales de los dispositivos de almacenamiento de back-end. La btrfs-convertherramienta explota 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, mientras se conserva una copia sin modificar del sistema de archivos original. [67]
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 se vuelva permanente. Gracias a la naturaleza de copia en escritura de Btrfs, las versiones originales de los bloques de datos de archivo se conservan durante todas las modificaciones de archivos. Hasta que la conversión se vuelva permanente, solo los bloques que se marcaron como libres en ext2/3/4 se utilizan para almacenar 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). [67]
Todos los archivos convertidos están disponibles y se pueden escribir en ellos 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, que se puede montar por sí solo como una imagen de disco de solo lectura, lo que permite acceder al mismo tiempo a los sistemas de archivos originales y convertidos. Al eliminar este archivo disperso se libera espacio y la conversión se vuelve permanente. [67]
En las versiones 4.x del núcleo principal de Linux, la conversión ext3/4 en el lugar se consideró no probada y rara vez se usó. [67] Sin embargo, la función se reescribió desde cero en 2016 para btrfs-progs4.6. [47] y se ha considerado estable desde entonces.
La conversión en el lugar desde ReiserFS se introdujo en septiembre de 2017 con el kernel 4.13. [68]
Al crear un nuevo Btrfs, se puede utilizar un Btrfs existente como un sistema de archivos "semilla" de solo lectura. [69] 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 separar más tarde del Btrfs, en cuyo punto el reequilibrador simplemente copiará cualquier dato de semilla aún referenciado por el nuevo sistema de archivos antes de separarlo. 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, luego expulsar el disco para completar la instalación sin reiniciar. [70]
En su entrevista de 2009, Mason afirmó que se había planeado brindar soporte para cifrado para Btrfs. [71] Mientras tanto, una solución alternativa para combinar el cifrado con Btrfs es 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, [actualizar]los desarrolladores estaban trabajando para agregar un hash con clave como HMAC ( SHA256 ). [72]
Los sistemas Unix tradicionalmente dependen de los programas " fsck " para comprobar 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 solo si se lo ha recomendado "un desarrollador o un usuario experimentado". [73] A partir de agosto de 2022, la documentación de SLE recomienda utilizar un Live CD, realizar una copia de seguridad y utilizar la opción de reparación solo como último recurso. [74]
Hay otra herramienta, llamada btrfs-restore, que se puede utilizar para recuperar archivos de un sistema de archivos que no se puede montar, sin modificar el sistema de archivos dañado en sí (es decir, de forma no destructiva). [75] [76]
En condiciones normales de uso, Btrfs se autocura en su mayor parte y puede recuperarse de árboles raíz dañados en el momento del montaje, gracias a que realiza vaciados periódicos de datos en el almacenamiento permanente, por defecto cada 30 segundos. Por lo tanto, los errores aislados harán que se pierdan un máximo de 30 segundos de cambios en el sistema de archivos en el siguiente montaje. [77] Este período se puede cambiar especificando un valor deseado (en segundos) con la commitopción de montaje. [78] [79]
La propuesta original de Ohad Rodeh en USENIX 2007 señaló que los árboles B+ , que se utilizan ampliamente como estructuras de datos en disco para bases de datos, no podían permitir de manera eficiente instantáneas basadas en copia en escritura porque sus nodos de hoja estaban vinculados entre sí: si una hoja se copiaba en escritura, sus hermanos y padres también tendrían que estarlo, al igual que sus hermanos y padres y así sucesivamente hasta que se copiara todo el árbol. En su lugar, sugirió un árbol B modificado (que no tiene vinculación de hojas), con un refcount asociado a cada nodo del árbol pero almacenado en una estructura de mapa libre ad hoc y ciertas relajaciones a los algoritmos de equilibrio del árbol para hacerlos compatibles con la copia en escritura. El resultado sería una estructura de datos adecuada para un almacén de objetos de alto rendimiento que podría realizar instantáneas basadas en copia en escritura, al mismo tiempo que mantiene una buena concurrencia . [18]
Más tarde ese año, en Oracle, Mason comenzó a trabajar en un sistema de archivos con capacidad de captura de instantáneas que utilizaría esta estructura de datos casi exclusivamente, no solo para metadatos y datos de archivos, sino también de manera recursiva para rastrear la asignación de espacio de los propios árboles. Esto permitió que todo el recorrido y las modificaciones se canalizaran a través de una única ruta de código, en la que las características como la copia al escribir, la suma de comprobación y la duplicación debían implementarse solo una vez para beneficiar a todo el sistema de archivos. [80]
Btrfs está estructurado como varias capas de tales árboles, todos usando la misma implementación de árbol B. Los árboles almacenan elementos genéricos ordenados por una clave de 136 bits. Los 64 bits más significativos de la clave son un identificador de objeto único . Los ocho bits del medio son un campo de tipo de elemento: su uso está integrado en el código como un filtro de elementos en las búsquedas de árboles. Los objetos pueden tener múltiples elementos de múltiples tipos. Los 64 bits restantes (menos significativos) se usan de manera específica para cada tipo. Por lo tanto, los elementos del mismo objeto terminan adyacentes entre sí en el árbol, agrupados por tipo. Al elegir ciertos valores de clave, los objetos pueden colocar elementos del mismo tipo en un orden particular. [80] [4]
Los nodos de árbol interiores son simplemente listas planas de pares de claves y punteros, donde el puntero es el número de bloque lógico de un nodo secundario. Los nodos de hoja contienen claves de elementos empaquetadas en la parte delantera del nodo y datos de elementos empaquetados en el extremo, y los dos crecen uno hacia el otro a medida que la hoja se llena. [80]
Dentro de cada directorio, las entradas de directorio aparecen como elementos de directorio , cuyos bits menos significativos de 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 usan para la iteración porque están ordenados por su hash, permutándolos aleatoriamente de manera efectiva . Esto significa que las aplicaciones de usuario que iteran y abran archivos en un directorio grande generarían muchas más búsquedas de disco entre archivos no adyacentes, una pérdida de rendimiento notable en otros sistemas de archivos con directorios ordenados por hash como ReiserFS , [81] ext3 (con índices Htree habilitados [82] ) 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 tanto, la iteración sobre estos elementos de índice devuelve entradas aproximadamente en el mismo orden en que están almacenadas en el disco.
Los archivos con enlaces duros en múltiples 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 era un fallo de diseño que limitaba el número de enlaces duros del mismo directorio a la cantidad que pudiera caber en un solo bloque de árbol. (En el tamaño de bloque predeterminado de 4 KiB, una longitud de nombre de archivo promedio 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 en este límite. [83] El límite finalmente se eliminó [84] (y a partir de octubre de 2012 se fusionó [85] pendiente de lanzamiento en Linux 3.7) al introducir elementos de referencia extendidos de desbordamiento para contener nombres de archivo de enlaces duros que de otra manera no encajarían.
Los datos de archivo se guardan fuera del árbol en extensiones , que son ejecuciones contiguas de bloques de datos de disco. Los bloques de extensión tienen un tamaño predeterminado de 4 KiB, no tienen encabezados y solo contienen datos de archivo (posiblemente comprimidos). En las extensiones comprimidas, los bloques individuales no se comprimen por separado; en cambio, el flujo de compresión abarca toda la extensión.
Los archivos tienen elementos de datos de extensión para rastrear las extensiones que contienen su contenido. El valor clave del elemento es el desplazamiento del byte inicial de la extensión. Esto permite realizar búsquedas eficientes en archivos grandes con muchas extensiones, ya que la extensión correcta para cualquier desplazamiento de archivo determinado se puede calcular con solo una búsqueda en árbol.
Las instantáneas y los archivos clonados comparten extensiones. Cuando se sobrescribe una pequeña parte de una extensión grande, la copia en escritura resultante puede crear tres extensiones nuevas: una pequeña que contiene los datos sobrescritos y dos grandes con datos sin modificar a cada lado de la sobrescritura. Para evitar tener que volver a escribir los datos sin modificar, la copia en escritura puede crear extensiones de extremo , o extensiones que son simplemente porciones de extensiones existentes. Los elementos de datos de extensión permiten esto al incluir un desplazamiento en la extensión que están rastreando: los elementos para los extremos son aquellos con desplazamientos distintos de cero. [4]
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 valores clave 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 extensiones de metadatos preferidas (nodos de árbol) y extensiones de datos (contenido de archivo). La relación predeterminada de grupos de bloques de datos a metadatos es 1:2. Su objetivo es utilizar conceptos del asignador de bloques de Orlov para asignar archivos relacionados juntos y resistir la fragmentación dejando espacio libre entre los grupos. (Sin embargo, los grupos de bloques 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 hacia atrás al nodo del árbol o archivo que ocupa esa extensión. Puede haber múltiples referencias hacia atrás si la extensión se comparte entre instantáneas. Si hay demasiadas referencias hacia atrás para que quepan en el elemento, se desbordan en elementos de referencia de datos de extensión individuales . Los nodos de árbol, a su vez, tienen referencias hacia atrás a sus árboles contenedores. Esto hace posible encontrar qué extensiones o nodos de árbol están en cualquier región del espacio haciendo una búsqueda de rango de árbol B en un par de desplazamientos que encierran esa región, luego siguiendo las referencias hacia atrás. Para reubicar datos, esto permite un recorrido ascendente eficiente desde los bloques reubicados para encontrar y corregir rápidamente todas las referencias hacia abajo 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 de manera eficiente su almacenamiento en línea.
El árbol de asignación de extensiones, al igual que todos los demás árboles del sistema de archivos, es de tipo copia-en-escritura. Las escrituras en el sistema de archivos pueden, por lo tanto, provocar una cascada en la que los nodos del árbol modificados y los datos de archivo resulten en la asignación de nuevas extensiones, lo que provoca que el propio árbol de extensiones cambie. Para evitar la creación de un bucle de retroalimentación , los nodos del árbol de extensiones que todavía están en la memoria pero que aún no se han asignado al disco pueden actualizarse en el lugar 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 el árbol de asignación de extensiones 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 el disco (a partir de Linux 2.6.37, a través de la space_cacheopción mount [86] ) como extensiones especiales que están exentas de la suma de comprobación y la copia en escritura.
Las sumas de comprobación CRC-32C se calculan tanto para los datos como para los metadatos y se almacenan como elementos de suma de comprobación en un árbol de suma de comprobación . Hay espacio para 256 bits de sumas de comprobación de metadatos y hasta un nodo completo (aproximadamente 4 KB o más) para sumas de comprobación de datos. Btrfs tiene disposiciones para que se agreguen algoritmos de suma de comprobación adicionales en futuras versiones del sistema de archivos. [37] [87]
Hay un elemento de suma de comprobación por cada serie contigua de bloques asignados, y las sumas de comprobación por bloque se empaquetan de extremo a extremo en los datos del elemento. Si hay más sumas de comprobación de las que caben, se vuelcan en otro elemento de suma de comprobación en una nueva hoja. Si el sistema de archivos detecta una falta de coincidencia en la suma de comprobación al leer un bloque, primero intenta obtener (o crear) una buena copia de este bloque desde otro dispositivo, si se utilizan técnicas de duplicación interna o RAID. [88] [89]
Btrfs puede iniciar una verificación en línea de todo el sistema de archivos activando un trabajo de limpieza del sistema de archivos que se realiza en segundo plano. El trabajo de limpieza escanea todo el sistema de archivos para comprobar su integridad e intenta automáticamente informar y reparar cualquier bloque defectuoso que encuentre en el proceso. [88] [90]
Una solicitud fsync confirma los datos modificados inmediatamente en un almacenamiento estable. Las cargas de trabajo con un uso intensivo de fsync (como una base de datos o una máquina virtual cuyo sistema operativo en ejecución realiza fsync con frecuencia) podrían generar una gran cantidad de E/S de escritura redundante al obligar al sistema de archivos a copiar repetidamente al escribir y vaciar con frecuencia las partes modificadas de los árboles al almacenamiento. Para evitar esto, se crea un árbol de registro temporal por subvolumen para registrar las copias activadas por fsync al escribir. Los árboles de registro son autónomos, rastrean sus propias extensiones y mantienen sus propios elementos de suma de comprobación. Sus elementos se reproducen y se eliminan en la siguiente confirmación completa del árbol o (si hubo una falla del sistema) en el siguiente remontaje.
Los dispositivos de bloque se dividen en fragmentos físicos de 1 GiB para datos y 256 MiB para metadatos. [91] Los fragmentos físicos de varios dispositivos se pueden reflejar o agrupar 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 en él como un elemento de dispositivo y fragmentos lógicos como elementos de mapa de fragmentos , que proporcionan una asignación hacia adelante de direcciones lógicas a físicas al almacenar sus desplazamientos en los 64 bits menos significativos de su clave. Los elementos de mapa de fragmentos pueden ser de varios tipos diferentes:
N es la cantidad de dispositivos de bloque que aún tienen espacio libre cuando se asigna el fragmento. Si N no es lo suficientemente grande para la duplicación o el mapeo elegidos, entonces el sistema de archivos se queda efectivamente sin espacio.
Las operaciones de desfragmentación, reducción y reequilibrio requieren que las extensiones se reubiquen. Sin embargo, hacer una simple copia en escritura de la extensión que se reubica romperá 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 de trabajo para los metadatos afectados. La extensión que se va a reubicar primero se copia a su destino. Luego, siguiendo las referencias hacia arriba a través del árbol del sistema de archivos del subvolumen afectado, los metadatos que apuntan a la extensión anterior se actualizan progresivamente para apuntar a la nueva; todos los elementos recientemente actualizados se almacenan en el árbol de reubicación. Una vez que se completa 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. [93]
Todos los árboles del sistema de archivos (incluido el á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 una lista de direcciones físicas de fragmentos que pertenecen a los árboles de fragmentos y raíz en el superbloque . [94]
Los espejos de superbloque se mantienen en ubicaciones fijas: [95] 64 KiB en cada dispositivo de bloque, con copias adicionales de 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 actualizaciones entre espejos para proporcionar cierta nivelación del desgaste .
CONFIG_LBDla opción de configuración del núcleo (disponible desde la serie de núcleos 2.6.x ) esté habilitada para eliminar estos límites del núcleo. [103] [104]Se llama Butter FS o B-tree FS, pero todos los chicos geniales dicen Butter FS.
Chris Mason es el desarrollador fundador de btrfs, en el que comenzó a trabajar en 2007 mientras trabajaba en Oracle. Esto lleva a muchas personas a creer que btrfs es un proyecto de Oracle, pero no lo es. El proyecto pertenecía a Mason, no a su empleador, y sigue siendo un proyecto comunitario libre de la propiedad corporativa hasta el día de hoy.
También se ha añadido soporte para los sistemas de archivos ext4 y Btrfs...
planeamos agregar fsck en línea, deduplicación, cifrado y otras funciones que han estado en las listas de deseos de los administradores durante mucho tiempo.
A partir de DSM 6.0, los volúmenes de datos se pueden formatear como Btrfs
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
