De los archivos: en los años 90, los fanáticos de los sistemas operativos adoraban el conjunto de características avanzadas de BFS.
Es el día después del Día de la Independencia en los EE. UU. y gran parte de nuestro personal está regresando a sus máquinas de trabajo preferidas. Si esto fuera 1997 en lugar de 2018, eso significaría iniciar BeOS para algunos. El futuro de los sistemas operativos que nunca existió llegó hace poco más de 20 años, así que a la luz de las vacaciones, estamos resurgiendo esta guía para geeks. La pieza se publicó originalmente el 2 de junio de 2010; aparece sin cambios a continuación.
El sistema de archivos del sistema operativo Be, conocido simplemente como BFS, es el sistema de archivos para los sistemas operativos Haiku, BeOS y SkyOS. Cuando se creó a finales de los años 90 como parte del desafortunado proyecto BeOS, el conjunto de funciones avanzadas de BFS llamó la atención de inmediato a los expertos en sistemas operativos. Ese conjunto de características incluye:
- Un espacio de direcciones de 64 bits
- Uso del diario
- Lectura altamente multiproceso
- Compatibilidad con atributos de archivos extendidos similares a bases de datos
- Optimización para el acceso a archivos de transmisión
Una docena de años después, el legendario BFS aún merece exploración, por lo que hoy nos sumergimos, comenzando con algunos conceptos básicos del sistema de archivos y pasando a una discusión de las características anteriores. También conversamos con dos personas íntimamente familiarizadas con el sistema operativo: la persona que desarrolló BFS para Be y el desarrollador detrás de la versión de código abierto de BFS.
Una pequeña historia
BFS fue creado en 1997 por Dominic Giampaolo y Cyril Meurillon, quienes trabajaban en Be. Fue diseñado para ser multiproceso y liviano, y para admitir transmisión multimedia de alto volumen. También fue diseñado para admitir las funciones de base de datos del sistema de archivos Be anterior. Aunque se escribió en una época en que los sistemas normalmente tenían solo 8 MB de RAM y solo 9 GB de almacenamiento en disco, muchas de las decisiones de diseño con visión de futuro que se tomaron entonces siguen siendo válidas hoy en día.
BFS no terminó del todo cuando Be cerró sus puertas después de que Apple no lo comprara. En 2002, Axel Dörfler volvió a implementar BFS para Haiku como un proyecto de código abierto. La última parte de este artículo presenta una entrevista con Axel.
Antes de que podamos hablar sobre lo que hizo que BFS sea tan especial, primero debemos cubrir algunos conceptos básicos del sistema de archivos.
Conceptos básicos del sistema de archivos
En el nivel básico, existe un sistema de archivos para administrar los datos en dispositivos de almacenamiento permanente. Las funciones comunes a la mayoría de los sistemas de archivos incluyen:
- Creación de archivos y directorios
- Abrir, leer, escribir, eliminar y renombrar archivos
- Lectura, escritura y actualización de metadatos o atributos de archivos
Las características adicionales incluyen enlaces simbólicos, listas de control de acceso y mapeo de memoria.
Para obtener una descripción general de alto nivel de numerosos sistemas de archivos, consulte el artículo From BFS to ZFS: Past, Present and Future File Systems . Para una mirada más profunda a HPFS, NTFS, EXT2 y XFS alrededor del año 2000, consulte el capítulo 3 de Diseño práctico de sistemas de archivos .
Los siguientes términos son comunes en las discusiones sobre el sistema de archivos, por lo que debe revisar la lista y familiarizarse con los que aún no conoce:
Disco : Un medio de almacenamiento permanente de cierto tamaño. Un disco también tiene un sector o tamaño de bloque, que es la unidad mínima que el disco puede leer o escribir. El tamaño de bloque tradicional para los discos ha sido de 512 bytes, pero ahora se acerca a los 4096 bytes para los discos más nuevos.
Bloque : La unidad más pequeña grabable por un disco o sistema de archivos. Todo lo que hace un sistema de archivos se compone de operaciones realizadas en bloques. Un bloque del sistema de archivos siempre tiene el mismo tamaño o es más grande (en múltiplos enteros) que el tamaño del bloque del disco.
Mapa de bits : no es una imagen, sino una estructura de datos que determina qué bloques de un disco están libres o usados.
Partición : Un subconjunto de todos los bloques en un disco. Un disco puede tener varias particiones.
Volumen : El nombre dado a una colección de bloques en algún medio de almacenamiento (es decir, un disco). Es decir, un volumen puede ser todos los bloques en un solo disco, una parte de la cantidad total de bloques en un disco, o incluso puede abarcar varios discos y ser todos los bloques en varios discos. El término "volumen" se utiliza para referirse a un disco o partición que se ha inicializado con un sistema de archivos.
Superbloque : el área de un volumen donde un sistema de archivos almacena su información crítica de todo el volumen. Un superbloque generalmente contiene información como el tamaño de un volumen, el nombre de un volumen, etc.
Metadatos : Término general que se refiere a la información que trata sobre algo pero que no forma parte directamente de él. Por ejemplo, el tamaño de un archivo es información muy importante, pero no forma parte de los datos que se almacenan en el propio archivo. Entonces, los metadatos del archivo son datos sobre un archivo, y no en un archivo.
Registro en diario : un método para garantizar la corrección de los metadatos del sistema de archivos incluso en presencia de fallas de energía o reinicios inesperados.
I-node : el lugar donde un sistema de archivos almacena todos los metadatos necesarios sobre un archivo. El i-nodo también proporciona la conexión con el contenido del archivo y cualquier otro dato asociado con el archivo. El término "i-nodo" (que usaremos en este artículo) es histórico y se originó en Unix. Un i-nodo también se conoce como bloque de control de archivos (FCB) o registro de archivos.
Atributo : un nombre (como una cadena de texto) y un valor asociado con el nombre. El valor puede tener un tipo definido (cadena, entero, etc.), o puede ser simplemente un dato arbitrario. (1)
Características de BFS
Ahora que tenemos los conceptos básicos de nuestro sistema de archivos, veamos algunas de las características que hacen que BFS sea único.
En primer lugar, el direccionamiento de 64 bits de BFS significa que no importa cuán grandes sean los discos en el futuro, podrá formatear todo el disco con BFS. Puede crear particiones de más de 8 exabytes y, según el tamaño de bloque utilizado, puede crear archivos de más de 30 GB de tamaño.
Una de las características más importantes y ampliamente promocionadas de BFS es su soporte para atributos extendidos. Un ejemplo de la importancia de los atributos se ilustra con un ejemplo de archivos MP3. Los campos de información importantes para un archivo MP3 serían: título de la canción, banda, álbum, fecha de lanzamiento, tasa de codificación, duración, número de veces reproducidas. Si desea asociar esta información con cada archivo MP3 utilizando un sistema de archivos convencional, es posible que deba crear su propia base de datos para admitir la búsqueda, creación, actualización o eliminación de estos atributos a medida que su colección de música crece y cambia. Con BFS, por el contrario, estos atributos, o cualquier otro atributo, se pueden agregar al propio sistema de archivos. Esto significa que un programa para editar o reproducir archivos MP3 no necesita crear ni mantener una base de datos, ya que el sistema de archivos manejará estas funciones por usted.BFS admite la asociación de atributos con un archivo, ya sea bajo el control del programa o desde la línea de comandos. Los atributos se pueden buscar y ordenar por el sistema de archivos, como una extensión de cualquier aplicación. Cómo se hace esto se discutirá en detalle más adelante.
BFS admite la capacidad de crear una consulta persistente o 'en vivo' que observa los cambios en los archivos. Esta es una consulta que se conecta al sistema de archivos, buscando archivos que coincidan con los criterios de búsqueda. Bajo Haiku, estas consultas son fáciles de crear y sorprendentemente ligeras en recursos del sistema.
BFS está registrado, lo que significa que realiza un seguimiento de ciertas consistencias del sistema de archivos sobre la marcha y no necesita herramientas de consistencia del sistema de archivos como fsck o chkdsk. El registro en diario también contribuye a un arranque más rápido del sistema después de un apagado inesperado.
Internamente, BFS usa caracteres UTF-8 para nombres de archivos y directorios. Esto significa que puede usar prácticamente cualquier idioma, de forma nativa, en Haiku. Sin ningún esfuerzo adicional, puede localizar los nombres de los archivos en chino, caracteres alemanes con diéresis o cursiva árabe.
BFS da una consideración de rendimiento especial al acceso a archivos grandes. La creación y lectura de archivos grandes de video, audio o imagen son operaciones optimizadas en BFS.
Arquitectura BFS: la Supermanzana
El superbloque suele ser la estructura de datos de más alto nivel para un sistema de archivos. El superbloque BFS describe el disco físico, el área de diario y la indexación. Por razones obvias de rendimiento, el superbloque se mantiene en la RAM después de que se inicia el sistema.
typedef struct disk_super_block {
char name[B_OS_NAME_LENGTH];
int32 magic1;
int32 fs_byte_order;
uint32 block_size;
uint32 block_shift;
off_t num_blocks;
off_t used_blocks;
int32 inode_size;
int32 magic2;
int32 blocks_per_ag;
int32 ag_shift;
int32 num_ags;
int32 flags;
block_run log_blocks;
off_t log_start;
off_t log_end;
int32 magic3;
inode_addr root_dir;
inode_addr indices;
int32 pad[8];
} disk_super_block;
La estructura de nombre contiene el nombre del sistema de archivos. Se utilizan tres números mágicos para comprobar la coherencia, así como para la numeración de versiones. Fs_byte_order contiene el orden de los bytes y block_size contiene el recuento explícito de bytes; block_shift , utilizado como exponente de 2, también calculará el tamaño del bloque. Se trata de una redundancia intencionada que se utiliza para comprobar la coherencia de un sistema de archivos. Num_blocks contiene el número de bloques disponibles para el sistema de archivos y used_blocks contiene el número actualmente en uso. El campo de banderas determina si el estado de la supermanzana es limpio o sucio. Root_dirapunta a la raíz de todos los archivos y directorios. Índices apunta al comienzo de la sección de índice de atributos extendidos. La utilidad bfsinfo se puede utilizar para volcar el superbloque para el superbloque de un sistema.
I-nodos
Como la mayoría de los sistemas de archivos derivados de UNIX, BFS utiliza una estructura de nodos para realizar un seguimiento de las asignaciones de disco. La estructura bfs_inode se define a continuación. El i-node maneja los metadatos básicos del archivo, incluido el tiempo de creación del archivo, el propietario, el tamaño del archivo, la propiedad del grupo, dónde se almacenan los datos del archivo en el disco, etc. BFS no actualiza el tamaño del archivo hasta que se cierra un archivo. En las pruebas se encontró que esto proporcionaba una mejora sustancial en el rendimiento.
typedef struct bfs_inode { int32 magic1;
inode_addr inode_num;
int32 uid;
int32 gid;
int32 mode;
int32 flags;
bigtime_t create_time;
bigtime_t last_modified_time;
inode_addr parent;
inode_addr attributes;
uint32 type;
int32 inode_size;
binode_etc *etc;
data_stream data;
int32 pad[4];
int32 small_data[1];
} bfs_inode;
Se usa nuevamente un número mágico en bfs_inode para verificar la cordura y la recuperación de errores. Los números mágicos para BeOS y Haiku son los mismos para la compatibilidad, pero diferentes para la implementación de SkyOS. BFS utiliza los sectores del disco del archivo como el valor del i-nodo, lo que hace que las asignaciones de sectores sean una búsqueda directa. UID, GID y modo se utilizan para mantener el cumplimiento de POSIX.
flujos_de_datos
La estructura i-node contiene los atributos básicos de un archivo, pero no los datos reales del archivo en sí. Esto se hace a través de la estructura de miembro de datos. El miembro de datos está definido por la estructura data_stream :
typedef struct data_stream {
block_run direct[NUM_DIRECT_BLOCKS];
off_t max_direct_range; block_run indirect;
off_t max_indirect_range;
block_run double_indirect;
off_t max_double_indirect_range;
off_t size;
} data_stream;
La estructura data_stream asigna datos del disco físico a la API de flujo de archivos. El acceso mediante data_streams está optimizado para el rendimiento, sin pasar por la memoria caché del sistema y utilizando DMA dentro y fuera de la memoria del usuario. En las pruebas comparativas, BFS puede lograr un alto rendimiento que se acerca a las tasas máximas de transferencia de disco.
Funciones de base de datos usando atributos extendidos
Como se mencionó anteriormente, el manejo de atributos es una función importante del sistema de archivos. El HFS de Mac fue el primer sistema de archivos que usó ampliamente los atributos de los archivos en apoyo de las GUI. Tenga en cuenta que un sistema operativo con ventanas debe persistir y administrar muchos atributos de la GUI, como el tamaño del marco, la ubicación, el color, el texto, etc., y debe optimizar el acceso para un tiempo de respuesta rápido.
BFS admite atributos extendidos en forma de asociaciones clave/valor con archivos. Las claves tienen un tipo fijo y se pueden agregar en cualquier momento. Los tipos válidos son string, time, double, float, int, boolean, raw e image. Si se indexa una clave, la búsqueda básica en una clave se optimiza en gran medida. Las siguientes son herramientas de línea de comandos para administrar atributos de archivos extendidos.
- addattr key value filename: agrega el par clave/valor al archivo especificado
- catattr key filename: muestra el valor del nombre de campo especificado.
- listattr filename: enumera los atributos asociados de un archivo, sus tipos y sus tamaños, en bytes.
- rmattr key filename: elimina un atributo del archivo especificado.
Los nuevos campos se crean globalmente con mkindex. Por ejemplo,
- mkindex --type=indextype index: crea un nuevo índice, de tipo long, sobre el volumen actual.
- reindex sourcefile filename: agrega la clave de un archivo a un índice si el índice se crea después de los atributos del archivo.
- Índice rmindex : elimina un atributo del volumen actual, dejándolo no disponible para su uso.
- lsindex : enumera todos los atributos
En Haiku, el acceso a los atributos de los archivos se admite gráficamente a través del Rastreador, así como con atajos de teclado. Cualquier objeto en Haiku que tenga una representación gráfica tiene el atributo _trk/pinfo_le establecido con su posición de icono de archivo. El atributo BEOS:TYPE contiene la asociación de aplicaciones para un archivo. Puede encontrar más detalles sobre el uso de atributos aquí .
Aquí y aquí se proporciona información adicional y ejemplos del uso de atributos de archivo .
Buscando con Query
Query es la herramienta de línea de comandos utilizada para buscar atributos coincidentes. Es más fácil de usar que la utilidad de línea de comando "buscar" de UNIX.
Estos son algunos ejemplos de la sintaxis de consulta:
query "((name="**")&&(BEOS:TYPE=="audio/x-wav"))"- encuentra todos los archivos con tipo MIME de "wav". Útil si tiene archivos wav a los que les falta la extensión .wav.
query "(last_modified >= %yesterday%)"- encuentra archivos más antiguos que ayer
El resultado de la consulta se puede utilizar con herramientas de secuencias de comandos desde la línea de comandos de la siguiente manera:
touch 'query ((last_modified< %yesterday%)&&(BEOS:TYPE=="audio/mpeg"))'
Esto actualizará la hora de última modificación en todos los archivos MP3 con una hora de última modificación más antigua que ayer.
Aquí se proporciona información adicional sobre secuencias de comandos con consulta .
Su equivalente en la interfaz gráfica de usuario de Haiku es "buscar", que se encuentra en la barra del escritorio y se documenta aquí . Todas las consultas de búsqueda se almacenan en caché durante 7 días y aparecen en la lista desplegable.
Consultas en vivo
Una característica especialmente interesante de BFS es la función Live Query. Cuando utilice Buscar, arrastre el nombre de una consulta de la lista de selección/selección y arrástrelo al escritorio o al Rastreador. Esto engancha la consulta en el sistema de archivos y la guarda. Cada vez que se crea o elimina un archivo que coincide con los criterios de consulta, la lista de consultas se actualiza. Las consultas en vivo se admiten de forma nativa en BFS y utilizan recursos sorprendentemente pequeños.
Las aplicaciones usan atributos
Haiku Mail Kit es un ejemplo de una aplicación que hace un uso intensivo de los atributos. El correo de Haiku no tiene su propia base de datos para almacenar y administrar archivos de correo electrónico. En su lugar, almacena cada correo electrónico directamente en el sistema de archivos BFS y utiliza más de 15 atributos específicos de correo electrónico para buscar y ordenar. ¿Te imaginas tener 8 exabytes de correo electrónico? Haiku hace esto teóricamente posible.
Este es un gran ejemplo de cómo abstraer la funcionalidad de aplicaciones individuales y ubicarla en el sistema operativo o, en este caso, en el sistema de archivos. Debido a que BFS admite atributos extendidos, cualquier aplicación puede usar la poderosa capacidad de base de datos del sistema de archivos sin tener que reinventar la rueda.
Optimización de búsquedas de atributos
Dado que cada archivo en BFS podría tener potencialmente muchos atributos extendidos, y potencialmente podría haber cientos de miles de archivos, existe una gran necesidad de optimizar el acceso a los atributos. En BFS, cada índice se implementa como una estructura de datos de árbol B+. El árbol B+ es una estructura de datos de árbol ordenada y equilibrada que proporciona una búsqueda muy rápida y escala muy bien. No es de extrañar que también se use para administrar estructuras de directorios y se use ampliamente en otros sistemas de archivos, como NTFS. Los índices BFS están muy optimizados para búsquedas de la forma:
query “(name==”temp”)”oquery “(name >”111”)”
Los índices BFS no están optimizados para búsquedas de expresiones regulares de la forma:
query “(name==[aA][bB][cC])”
Estas búsquedas se degradan de una búsqueda binaria a una búsqueda secuencial y podrían llevar mucho más tiempo en un sistema de archivos grande.
Las consultas que usan una expresión regular pero comienzan con una expresión fija se optimizan en Haiku, por ejemplo, query “(name==temp[1234])”se ejecutarán más rápido que query “(name==[tT]emp[1234])”.
Diario
Las computadoras con almacenamiento en disco pueden experimentar muchos tipos de modos de falla. El material magnético de un sector del disco puede estropearse, el servomecanismo que mueve el cabezal del disco puede fallar, los componentes electrónicos que interactúan con la computadora pueden fallar o el usuario puede reiniciar la máquina en medio de una operación de escritura en el disco. Si ejecuta un disco el tiempo suficiente, eventualmente la electrónica o la mecánica de un disco fallarán. Por lo general, no es necesario esperar mucho para que un usuario impaciente se reinicie durante una operación de escritura de archivos. Desafortunadamente, esto es una ocurrencia bastante común y puede tener resultados devastadores en un sistema de archivos.
Considere la siguiente situación. Un usuario ha creado un archivo y es el proceso de guardarlo en el disco. Tal vez sea un desarrollador trabajando en un proyecto atrasado. El sistema de archivos debe realizar varias actualizaciones antes de que este archivo se guarde por completo. Primero debe guardar el contenido del archivo. Debe guardar los metadatos del archivo, fecha de creación, propietario, tamaño del archivo, etc. También debe actualizar el superbloque. Considere lo que sucede cuando un sistema se apaga antes de que se completen estas operaciones. Además de perder su valioso trabajo, las estructuras de datos pueden corromperse y apuntar a i-nodos y bloques que no existen. Además de ser aún más tarde, su sistema de archivos puede fallar posteriormente al arrancar, perdiendo todos sus otros archivos.
El registro en diario, o el registro del sistema de archivos, alivia algunos de estos problemas. Si bien el diario no garantiza que un reinicio prematuro no perderá su archivo, sí garantiza que no corromperá su sistema de archivos.
Considere el siguiente ejemplo de cómo funciona el diario. Digamos que un usuario crea un nuevo archivo y lo guarda. Los datos se deben guardar en el disco y también se debe guardar una nueva entrada de directorio con los metadatos correctos. Antes de que ocurran estas operaciones de disco, BFS bloquea los bloques no escritos en la RAM y crea entradas de registro en el diario del sistema de archivos para cada bloque que está a punto de escribirse. Después de que cada bloque se vacía con éxito en el disco, las entradas del diario se marcan como completadas. Si el sistema se apaga antes de que los bloques se vacíen con éxito, las entradas del diario enumerarán las operaciones incompletas. Cuando el sistema se reinicia, inspecciona el diario en busca de entradas que no estén completas. Las entradas restantes se pueden "reproducir" cuando el sistema se reinicia para completar con éxito la operación de escritura, o todo se puede "revertir".y la operación abortada. De cualquier manera, el sistema de archivos se deja en un estado consistente donde la estructura del directorio y los metadatos coinciden con precisión con los datos del archivo.
En BFS, el diario registra cualquier cambio realizado en el directorio, el bloque de mapa de bits, los i-nodes y los atributos extendidos. No registra en diario los datos reales del usuario. De esta manera, el diario protege la consistencia del sistema de archivos, pero no proporciona funciones de recuperación de datos como una matriz de discos redundantes o RAID.
Si bien no es inmune a todos los errores de disco, BFS es resistente al modo de falla común de un apagado prematuro del sistema. Los sistemas de archivos sin registro en diario, como Linux EXT2, son vulnerables a las inconsistencias del sistema de archivos y dependen de largos procesos de exploración para la recuperación. BFS no necesita escanear el disco y Haiku puede iniciarse rápidamente después de un apagado prematuro.
Mejoras de Haiku BFS sobre BeOS
La versión de BFS de Haiku tiene una serie de mejoras con respecto a la implementación original de BeOS BFS. El árbol B+ es más robusto. Haiku BFS utiliza un caché de archivos para datos de archivos además de un caché de bloques. Esto resultó en un factor de 10 de mejora de la velocidad. El BFS de Haiku implementa el tiempo de cambio de estado para los archivos y también tiene una capacidad de estado de archivo más detallada. El archivo POSIX atime se omitió de BeOS BFS por motivos de rendimiento. Haiku BFS incluye una consulta optimizada para expresiones regulares híbridas que permite mezclar una cadena estática con una expresión regular. Se agregaron nuevas herramientas de inspección bfsinfo, bfswhich, chkindex y recovery para Haiku BFS. Se agregó el comando reindex para mejorar la indexación de atributos extendidos.
Una breve entrevista con un desarrollador sénior de BeOS, que trabajó en BFS
(Pide que no se use su nombre, para cumplir con los deseos de su actual empleador)
El libro Practical File System Design describe el entorno de desarrollo de BeOS como corto de tiempo y escaso para los desarrolladores. ¿Cuáles fueron algunos de los aspectos positivos de ese ambiente?
Era simplemente un lugar divertido para trabajar en ese momento. Todos nos llevábamos muy bien, amábamos lo que hacíamos y todos nos alimentábamos de la energía de los demás. Todo el mundo era de primera categoría y era simplemente sin parar. Por lo general, obtienes uno o dos de esos aspectos en una empresa, pero cuando los tienes todos, es un ambiente muy embriagador: el cambio es rápido, el progreso es bueno, sientes que realmente estás haciendo algo importante y es muy divertido. .
Desde la concepción hasta el lanzamiento, ¿cuánto tiempo llevó codificar y depurar BFS?
Diez u once meses. Recibí la ayuda de otro ingeniero para escribir el código que manejaba la escritura en los bloques indirectos en un archivo.
¿Qué herramientas usó para desarrollar y depurar BFS?
Emacs, make y gcc. Inicialmente, hice algunos prototipos en el espacio del usuario y, por lo tanto, pude usar gdb, pero una vez que entró en el kernel, todo fue "Bienvenido a Kernel Debugging Land" de ahí en adelante.
¿Cuál fue el mayor desafío en el desarrollo de BFS?
Tratar de hacerlo en un período de tiempo tan corto y al mismo tiempo admitir todas las funciones que queríamos.
¿BFS influyó en el diseño de cualquier sistema de archivos posterior?
Improbable.
¿Cuáles son algunos temas candentes de los sistemas de archivos en la actualidad?
La integridad de datos y la deduplicación de datos son probablemente las áreas de mayor interés en este momento. Las personas también pasan mucho tiempo tratando de descubrir cómo proporcionar un almacenamiento confiable frente a componentes poco confiables. RAID-5/6 está bien, pero a medida que aumenta el tamaño de las unidades, a muchas personas les preocupa que cuando ocurra una falla, sean vulnerables a una falla total si otra unidad falla antes de que terminen con la reconstrucción.
¿Qué nuevas funciones o actividades admitirá la próxima generación de sistemas de archivos?
No estoy seguro. Creo que pasará un poco de tiempo antes de que resolvamos qué capa es el lugar correcto para todas las diferentes partes del problema del "almacenamiento". ZFS ha seguido el camino de poner todo en el FS. Otras personas están poniendo un conjunto diferente de cosas. Está bastante claro que parte de la funcionalidad que existía en BFS *no* pertenece al FS.
En tu opinión, ¿qué película de ciencia ficción tiene el mejor uso de una computadora?
Mmmm, no estoy seguro. ¿Star Trek? Sus computadoras hacen todo y tienen una interfaz multitáctil y no pasan mucho tiempo jugando con ellas.
Una breve entrevista con Axel Dörfler, desarrollador de BFS de código abierto
Antes de BFS, ¿tenía experiencia previa trabajando con sistemas de archivos?
Tuve que escribir una aplicación para recuperar algunos datos de un disco duro particionado BFS. Eso me dio todo el conocimiento que necesitaba para escribir BFS.
¿Cuál fue la parte más difícil de reescribir BFS?
Asegurarse de que la implementación del árbol B+ se comportara correctamente, ya que la utilizada en el BFS original (como se menciona en el libro de Dominic) era bastante inestable e ineficiente.
¿Cuál fue la parte más fácil?
La implementación real de solo lectura de BFS, ya que podía reutilizar la mayor parte del código que había escrito para la recuperación.
¿Encontraste alguna sorpresa al reescribir BFS?
Sí, hay algunas cosas bastante ilógicas como el registro que usa block_runs, pero requiere que tengan una longitud de uno, o la casi superflua implementación de doble bloque indirecto.
¿Alguna vez tuviste alguna discusión con Dominic sobre BFS?
Sí, pero en realidad no detallaron sus fallas, sino mi implementación.
¿Qué cambiarías en BFS 2.0?
Mucho.
¿Cuánto tiempo tomó la codificación?
Honestamente no recuerdo. Creo que la parte de solo lectura tomó solo dos semanas más o menos, mientras que la parte de escritura tomó mucho más tiempo, y aún tomó más tiempo para que fuera completamente compatible con el BFS de Be.
¿Cuál fue el error más grande y cómo lo solucionaste?
El error más molesto fue el error "Vnode ID ya existe": había una docena de razones por las que esto podría suceder, y eso minimizó la alegría de haber encontrado otro problema con él (solo una parte de ellos estaban en BFS en sí mismo, sin embargo).
Todavía está allí en una nueva encarnación como el error #5262, por cierto, aunque esto podría tener razones completamente ajenas (como la corrupción de la memoria).
¿Qué lecciones aprendiste al reescribir BFS?
Que es mucho más fácil tener un VFS en funcionamiento al escribir un sistema de archivos.
Por último, ¿cuál es su PC de desarrollo actual?
Dependiendo de dónde esté, es un ThinkPad T60 o un Core 2 Quad de dos años con gráficos Intel integrados.
Agradecimientos
Este artículo se basó en gran medida en el libro Diseño práctico de sistemas de archivos con Be File System . Rara vez se documenta un sistema de archivos con tanto detalle y de forma tan legible. También gracias a Axel Dörfler por verificar los hechos.
Referencias
- Diseño Práctico de Sistema de Archivos con Be File System, (1)
- Módulos del sistema de archivos Haiku
- Kit de construcción del sistema de archivos BFS
- De BFS a ZFS
- NTFS
- Atributos del haiku
- La Biblia BeOS
- hacker escocés
- Sistemas de archivos en Linux
- Sistema de archivos EXT2
Sobre el Autor
Andrew Hudson es un gerente de proyectos técnicos independiente que vive en Florida, EE. UU. En su abundante tiempo libre, disfruta explorando cuevas y restaurando autos antiguos.