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 la copia -Principio de escritura (COW) con un administrador de volumen lógico (que no debe confundirse con LVM de Linux ), desarrollado juntos. Fue fundado por Chris Mason en 2007 [15] para su uso en Linux , y desde noviembre de 2013, el formato en disco del sistema de archivos se ha declarado estable en el kernel de Linux . [dieciséis]
Btrfs está destinado a abordar la falta de agrupación , instantáneas , sumas de verificación y expansión integral de múltiples dispositivos en los sistemas de archivos Linux . [9] Chris Mason, el autor principal de Btrfs, declaró que su objetivo era "permitir que [Linux] escale para el almacenamiento que estará disponible. El escalado no se trata sólo de abordar el almacenamiento, sino que también significa ser capaz de administrarlo y gestionarlo". con una interfaz limpia que permite a la gente ver lo que se está utilizando y lo hace más confiable". [17]
La estructura de datos central de Btrfs—el árbol B de copia en escritura —fue propuesta originalmente por el investigador de IBM Ohad Rodeh en una presentación en USENIX 2007. [18] Chris Mason, un ingeniero que trabajaba en ReiserFS para SUSE en ese momento, Se unió a Oracle ese mismo 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 tiene características mejoradas, no es un avance importante; 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 tenía reiser3 / 4 ". [21]
Btrfs 1.0, con formato en disco finalizado, estaba originalmente programado para su lanzamiento a finales 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 raíz. sistema de archivos durante la instalación. [24] [25] [26]
En julio de 2011, las funciones de desfragmentación y depuración automática 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ó a mejorar el rendimiento. [28] En junio de 2012, Chris Mason dejó Oracle por Fusion-io , que dejó 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 de SUSE Linux Enterprise en agosto. [31]
En 2015, se adoptó Btrfs como 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 función totalmente compatible (se ha incluido como una "vista previa de tecnología" desde RHEL 6 beta), señalando que permanecería disponible en la serie de lanzamientos 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, se seleccionó Btrfs 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 atómicamente una instantánea de copia en escritura de un archivo . Estos archivos clonados a veces se denominan reflinks , a la luz de la llamada al sistema del kernel 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 sólo 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 bajo ciertas circunstancias. [56] [57] Los bloques de datos reales no están duplicados; al mismo tiempo, debido a la naturaleza de copia en escritura (CoW) de Btrfs, las modificaciones realizadas en cualquiera de los archivos clonados no son visibles en el archivo original y viceversa. [58]
La clonación no debe confundirse con los enlaces físicos , que son entradas de directorio que asocian varios nombres de archivos con un solo archivo. Si bien los enlaces físicos 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]
La compatibilidad con esta característica Btrfs se agregó en la versión 7.5 de GNU coreutils , mediante 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 almacenamiento. [62] [10]
Un subvolumen Btrfs se puede considerar como un espacio de nombres de archivo POSIX separado , que se puede montar por separado pasando opciones subvolu subvolida la utilidad. También se puede acceder montando el subvolumen de nivel superior, en cuyo caso los subvolúmenes son visibles y accesibles como sus subdirectorios. [63]
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 subvolumen de nivel superior presenta sus subvolúmenes como subdirectorios. No es posible eliminar un subvolumen 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 forma 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 grabable, se puede tratar como una versión alternativa del sistema de archivos original. Por ejemplo, para volver a una instantánea, es necesario desmontar un subvolumen original modificado y montar la instantánea en su lugar. En ese momento, también se podrá eliminar el subvolumen original. [63]
La naturaleza de copia en escritura (CoW) de Btrfs significa que las instantáneas se crean rápidamente, aunque 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 con el 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 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. Teniendo eso disponible, se puede crear una instantánea de este nuevo volumen. [56]
Un subvolumen en Btrfs es bastante diferente de un volumen lógico tradicional de Logical Volume Manager (LVM). Con LVM, un volumen lógico es un dispositivo de bloque separado , mientras que un subvolumen Btrfs no lo es y no puede tratarse ni usarse de esa manera. [63] Hacer instantáneas dd o LVM de btrfs provoca la pérdida de datos si el original o la copia se montan mientras ambos están en la misma computadora. [sesenta y cinco]
Dado cualquier par de subvolúmenes (o instantáneas), Btrfs puede generar una diferencia binaria entre ellos (usando el btrfs sendcomando) que puede reproducirse más tarde (usando 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 periódicamente para implementar una forma simple de replicación del sistema de archivos o con el fin de realizar copias de seguridad incrementales . [49] [66]
Un grupo de cuota (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 principal, pero a partir de entonces genera un cargo por archivos nuevos y operaciones de copia en escritura en 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, es posible encontrar soluciones utilizando diferentes subvolúmenes 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 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, preservando al mismo tiempo una copia no modificada del sistema de archivos original. [67]
La conversión implica crear una copia de todos los metadatos 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 del archivo se conservan durante todas las modificaciones del archivo. Hasta que la conversión se vuelva permanente, solo los bloques que se marcaron como libres en ext2/3/4 se utilizan para contener 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 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 a los sistemas de archivos originales y convertidos en el mismo momento. Mismo tiempo. Eliminar este archivo disperso libera espacio y hace que la conversión sea permanente. [67]
En las versiones 4.x del kernel principal de Linux, la conversión local ext3/4 se consideró no probada y rara vez se usaba. [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 local desde ReiserFS se introdujo en septiembre de 2017 con el kernel 4.13. [68]
Al crear un nuevo Btrfs, un Btrfs existente se puede utilizar 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 en la semilla, como una forma de montaje de unión . Posteriormente, la semilla se puede separar de Btrfs, momento en el cual el reequilibrador simplemente copiará cualquier dato de semilla al que todavía haga referencia 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 en 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. [70]
En su entrevista de 2009, Chris Mason afirmó que se planificó 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 encima de esa capa.
A partir de 2020, [actualizar]los desarrolladores estaban trabajando para agregar hash con clave como HMAC ( SHA256 ). [72]
Los sistemas Unix tradicionalmente dependen de programas " fsck " para verificar y reparar 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 sólo si ha sido asesorado por "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 únicamente la opción de reparación como último recurso. [74]
Hay otra herramienta, llamada btrfs-restore, que se puede utilizar para recuperar archivos de un sistema de archivos desmontable, sin modificar el sistema de archivos roto (es decir, de forma no destructiva). [75] [76]
En uso normal, Btrfs se repara principalmente a sí mismo y puede recuperarse de árboles raíz rotos en el momento del montaje, gracias a que realiza descargas periódicas de datos al almacenamiento permanente, de forma predeterminada cada 30 segundos. Por lo tanto, los errores aislados provocará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 usan 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 hoja estaban vinculados entre sí: si se copiaba una hoja al escribir, 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 enlaces de hoja), con un recuento asociado a cada nodo del árbol pero almacenado en una estructura de mapa libre ad hoc y ciertas flexibilizaciones en los algoritmos de equilibrio del árbol para que sean fáciles de copiar 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 de copia en escritura, manteniendo al mismo tiempo una buena concurrencia . [18]
Más tarde ese año, en Oracle, Chris Mason comenzó a trabajar en un sistema de archivos con capacidad de instantáneas que usaría esta estructura de datos casi exclusivamente, no solo para metadatos y datos de archivos, sino también de forma recursiva para rastrear la asignación de espacio de los propios árboles. Esto permitió que todos los recorridos y modificaciones se canalizaran a través de una única ruta de código, frente a la cual características como copia en escritura, suma de verificación y duplicación debían implementarse solo una vez para beneficiar a todo el sistema de archivos. [80]
Btrfs está estructurado como varias capas de dichos árboles, y todos utilizan 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 importantes de la clave son una identificación de objeto única . Los ocho bits del medio son un campo de tipo de elemento: su uso está integrado en el código como filtro de elementos en búsquedas de árbol. Los objetos pueden tener varios elementos de varios tipos. Los 64 bits restantes (menos significativos) se utilizan de formas específicas del tipo. Por lo tanto, los elementos del mismo objeto terminan uno al lado del otro en el árbol, agrupados por tipo. Al elegir ciertos valores clave, los objetos pueden colocar elementos del mismo tipo en un orden particular. [80] [4]
Los nodos interiores del árbol son simplemente listas planas de pares clave-puntero, 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 frontal del nodo y datos de elementos empaquetados en el final, y los dos crecen uno hacia el otro a medida que la hoja se llena. [80]
Dentro de cada directorio, las entradas del directorio aparecen como elementos del directorio , cuyos bits menos significativos de valores 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 del directorio juntos pueden actuar así como un índice para búsquedas de ruta a inodo, pero no se utilizan para la iteración porque están ordenados por su hash, permutándolos efectivamente de forma aleatoria . Esto significa que las aplicaciones de usuario que iteran y abren 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 mediante hash, como ReiserFS , [81] ext3 (con Htree -indexes enable [82] ) y ext4, todos los cuales tienen nombres de archivos con hash TEA . Para evitar esto, cada entrada de directorio tiene un elemento de índice de directorio , cuyo valor clave del elemento se establece en un contador por directorio que aumenta con cada nueva entrada de directorio. La iteración sobre estos elementos del índice devuelve entradas aproximadamente en el mismo orden en que se almacenan en el disco.
Los archivos con enlaces físicos en varios directorios tienen varios elementos de referencia, uno para cada directorio principal. Los archivos con múltiples enlaces físicos en el mismo directorio empaquetan todos los nombres de archivo de los enlaces en el mismo elemento de referencia. Este fue un error de diseño que limitó la cantidad de enlaces físicos del mismo directorio a todos los que pudieran caber en un solo bloque de árbol. (Con el 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). Aplicaciones que hacían un uso intensivo de múltiples enlaces físicos del mismo directorio, como Se observó que 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) mediante la introducción de elementos de referencia extendidos para contener nombres de archivos de enlaces físicos que de otro modo no encajarían.
Los datos del archivo se mantienen fuera del árbol en extensiones , que son ejecuciones contiguas de bloques de datos del disco. Los bloques de extensión tienen un tamaño predeterminado de 4 KiB, no tienen encabezados y contienen solo datos de archivos (posiblemente comprimidos). En extensiones comprimidas, los bloques individuales no se comprimen por separado; más bien, 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, porque la extensión correcta para cualquier desplazamiento de archivo determinado se puede calcular con una sola 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 sobre escritura resultante puede crear tres extensiones nuevas: una pequeña que contiene los datos sobrescritos y dos grandes con datos no modificados en cada lado de la sobrescritura. Para evitar tener que reescribir datos no modificados, la copia en escritura puede crear extensiones de sujetalibros , o extensiones que son simplemente porciones de extensiones existentes. Los elementos de datos de extensión permiten esto al incluir una compensación en la medida en que están rastreando: los elementos para sujetalibros son aquellos con compensaciones distintas 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 (contenidos de archivos). La proporción predeterminada de datos a grupos de bloques de metadatos es 1:2. Su objetivo es utilizar conceptos del asignador de bloques de Orlov para asignar archivos relacionados y resistir la fragmentación dejando espacio libre entre 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 del 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 al nodo del árbol o al archivo que ocupa esa extensión. Puede haber varias referencias anteriores si la extensión se comparte entre instantáneas. Si hay demasiadas referencias anteriores para caber en el elemento, se desglosan en elementos de referencia de datos de extensión individuales . Los nodos de árbol, a su vez, tienen referencias a los árboles que los contienen. 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 compensaciones que abarcan esa región y luego siguiendo las referencias anteriores. 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 de manera eficiente su almacenamiento en línea.
El árbol de asignación de extensiones, como ocurre con todos los demás árboles del sistema de archivos, es de copia en escritura. Por lo tanto, las escrituras en el sistema de archivos pueden provocar una cascada en la que los nodos del árbol y los datos del archivo modificados dan como resultado 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 extensión que todavía están en la memoria pero que aún no están comprometidos en el disco pueden actualizarse en su 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 . En la práctica, sin embargo, 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 conservan en el disco (a partir de Linux 2.6.37, mediante la space_cacheopción de montaje [86] ) como extensiones especiales que están exentas de suma de comprobación y copia en escritura.
Las sumas de verificación CRC-32C se calculan tanto para datos como para metadatos y se almacenan como elementos de suma de verificación en un árbol de suma 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 tiene disposiciones para agregar algoritmos de suma de verificación adicionales en versiones futuras del sistema de archivos. [37] [87]
Hay un elemento de suma de verificación por ejecución contigua de bloques asignados, con sumas de verificación por bloque empaquetadas de un extremo a otro en los datos del elemento. Si hay más sumas de verificación de las que caben, se derraman en otro elemento de suma de verificación en una hoja nueva. Si el sistema de archivos detecta una discrepancia en la suma de comprobación mientras lee 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 una tarea de limpieza del sistema de archivos que se realiza en segundo plano. El trabajo de limpieza escanea todo el sistema de archivos en busca de integridad e intenta automáticamente informar y reparar cualquier bloque defectuoso que encuentre en el camino. [88] [90]
Una solicitud fsync envía los datos modificados inmediatamente a un almacenamiento estable. Las cargas de trabajo con gran cantidad de fsync (como una base de datos o una máquina virtual cuyo sistema operativo ejecuta fsyncs con frecuencia) podrían generar una gran cantidad de E/S de escritura redundantes al obligar al sistema de archivos a copiar en escritura repetidamente y vaciar partes de los árboles que se modifican con frecuencia para almacenamiento. Para evitar esto, se crea un árbol de registro temporal por subvolumen para registrar las copias activadas por fsync durante la escritura. Los árboles de troncos son autónomos, rastrean sus propias extensiones y mantienen sus propios elementos de suma de verificación. Sus elementos se reproducen y eliminan en la siguiente confirmación del árbol completo o (si hubo una falla del sistema) en el siguiente reinicio.
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 duplicar o dividir 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 rastrea esto almacenando cada dispositivo en él como un elemento de dispositivo y fragmentos lógicos como elementos de mapa de fragmentos , que proporcionan un mapeo directo de direcciones lógicas a físicas al almacenar sus compensaciones en los 64 bits menos significativos de su clave. Los elementos del mapa fragmentado 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/mapeo elegido, entonces el sistema de archivos efectivamente se ha quedado 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 de reubicación 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 primero se copia en su destino. Luego, al seguir 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; cualquier elemento recién actualizado se almacena 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 homólogos en el subvolumen afectado y el árbol de reubicación se descarta. [93]
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 iniciar un montaje, se almacena en el superbloque una lista de direcciones físicas de fragmentos que pertenecen a los árboles de fragmentos y raíz . [94]
Los espejos de superbloque se mantienen en ubicaciones fijas: [95] 64 KiB en cada dispositivo de bloque, con copias adicionales a 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 superbloque se actualizan en conjunto, excepto en el modo SSD , que alterna actualizaciones entre los espejos para proporcionar cierta nivelación del desgaste .
Oracle Linux desde la versión 7 [96] [97]
CONFIG_LBDla opción de configuración del kernel (disponible desde la serie de kernel 2.6.x ) esté habilitada para eliminar estos límites del kernel. [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 mucha gente a creer que btrfs es un proyecto de Oracle; no lo es. El proyecto pertenecía a Mason, no a su empleador, y sigue siendo un proyecto comunitario libre de propiedad corporativa hasta el día de hoy.
También se ha agregado soporte para los sistemas de archivos ext4 y Btrfs...
En futuras versiones planeamos agregar fsck en línea, deduplicación, cifrado y otras características 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}
