Se ha publicado la segunda entrevista con Eduard Shishkin, desarrollador del sistema de archivos Reiser4.
Para comenzar, recuerde a los lectores dónde y para quién trabaja.
Trabajo como Arquitecto Principal de Almacenamiento en Huawei Technologies, Centro de Investigación Alemán. En el departamento de virtualización me ocupo de diversos aspectos del almacenamiento de datos. Mis actividades no están relacionadas con un sistema operativo específico.
¿Está actualmente comprometido con la rama principal del kernel?
Muy raramente y sólo si mi empleador lo requiere. La última vez fue hace unos tres años y envié parches para aumentar el rendimiento del almacenamiento compartido en hosts que utilizan el protocolo 9p (otro nombre para este negocio es VirtFS). Aquí hay que hacer una nota importante: aunque llevo mucho tiempo trabajando con Linux, nunca he sido un fanático de él, es decir, "respiro de manera uniforme", como con todo lo demás. En particular, si noto un defecto, puedo señalarlo como máximo una vez. Y para que luego puedas seguir a alguien y persuadirlo, esto no sucederá.
Recuerdo la última vez, hace diez años, que fuiste bastante crítico con el estilo de desarrollo del kernel. Desde su punto de vista (o quizás desde su punto de vista corporativo), ¿ha cambiado algo? ¿La comunidad se ha vuelto más receptiva o no? Si no, ¿quién crees que es el culpable?
Nunca vi ningún cambio para mejor. El principal problema de la comunidad es la sustitución de la ciencia por tecnologías políticas, relaciones personales, opinión mayoritaria, populismo, consejos de “voces internas”, compromisos podridos, cualquier cosa que no sea ciencia. La informática, digan lo que digan, es ante todo una ciencia exacta. Y si alguien comienza a proclamar su propio valor para 2x2, diferente de 4, bajo la bandera "estilo Linux", o bajo alguna otra bandera, entonces es poco probable que esto traiga algo más que daño.
Todos los problemas se deben principalmente a la incompetencia y falta de educación de quienes toman las decisiones. Si un directivo es incompetente, no podrá tomar una decisión objetiva y adecuada. Si además es inculto, no podrá encontrar un especialista competente que le dé el consejo adecuado. Con una alta probabilidad, la elección recaerá en un estafador que dice "cosas aparentemente correctas". Siempre se desarrolla un ambiente corrupto en torno a líderes solitarios e incompetentes. Además, la historia no conoce excepciones a este respecto, y la comunidad es la confirmación más clara de ello.
¿Cómo evalúa el progreso en el desarrollo de Btrfs? ¿Este FS eliminó las enfermedades infantiles? ¿Cómo lo posicionaría usted mismo: como FS “para el hogar” o también para uso corporativo?
No me deshice de él. Todo lo que mencioné hace 11 años sigue siendo relevante hoy. Uno de los problemas de Btrfs que lo hace inadecuado para necesidades importantes es el problema del espacio libre. Ni siquiera me refiero al hecho de que se le pide al usuario que vaya al almacén en busca de un nuevo disco en situaciones en las que cualquier otro FS mostraría mucho espacio libre en la partición. La imposibilidad de completar una operación en un volumen lógico debido a la falta de espacio libre tampoco es lo peor. Lo peor es que un usuario sin privilegios casi siempre puede, eludir las cuotas de disco, privar a todos del espacio libre en un tiempo bastante corto.
Tiene este aspecto (probado para el kernel de Linux 5.12). Se inicia un script en un sistema recién instalado, que en un bucle crea archivos con ciertos nombres en el directorio de inicio, les escribe datos en ciertos desplazamientos y luego elimina estos archivos. Después de un minuto de ejecutar este script, no sucede nada inusual. Después de cinco minutos, la porción de espacio ocupado en la partición aumenta ligeramente. Al cabo de dos o tres horas alcanza el 50% (con un valor inicial del 15%). Y después de cinco o seis horas de trabajo, el script falla y aparece el error "no hay espacio libre en la partición". Después de esto, ya no podrá escribir ni siquiera un archivo 4K en su partición.
Ocurre una situación interesante: al final no escribiste nada en la partición y todo el espacio libre (alrededor del 85%) desapareció en alguna parte. El análisis de una sección sujeta a tal ataque revelará muchos nodos de árbol que contienen solo un elemento (un objeto equipado con una clave), de varios bytes de tamaño. Es decir, el contenido que anteriormente ocupaba el 15% del espacio en disco resultó estar "manchado" uniformemente en toda la partición, de modo que no hay ningún lugar para escribir un archivo nuevo, porque su clave es más grande que todas las existentes, y la gratuita Los bloques de la partición se han agotado.
Además, todo esto ya sucede en la configuración básica de Btrfs (sin instantáneas, subvolúmenes, etc.), y no importa cómo decida almacenar los cuerpos de los archivos en ese FS (como "fragmentos" en un árbol o como extensiones de bloques sin formato) - el resultado final será el mismo.
No podrá someter a otros sistemas de archivos ascendentes a tal ataque (sin importar lo que le digan). Expliqué la causa del problema hace mucho tiempo: se trata de una completa perversión del concepto de árbol B en Btrfs, lo que hace posible que degenere espontánea o intencionadamente. En particular, bajo ciertas cargas, su sistema de archivos se "desmoronará" continuamente durante el funcionamiento por sí solo, sin ayuda externa. Está claro que todo tipo de procesos en segundo plano "apremiantes" salvarán el día sólo en escritorios individuales.
En los servidores colectivos, un atacante siempre podrá “adelantarse” a ellos. El administrador del sistema ni siquiera podrá determinar quién exactamente lo acosó. La forma más rápida de solucionar este problema en Btrfs es restaurar la estructura de un árbol B normal, es decir. rediseñando el formato del disco y reescribiendo partes importantes del código Btrfs. Esto llevará entre 8 y 10 años, incluida la depuración, siempre que los desarrolladores sigan estrictamente los artículos originales sobre los algoritmos y estructuras de datos relevantes, y no jueguen al juego del "teléfono roto", como es habitual (y recomendado) en la industria "Linux". forma".
Aquí también debemos agregar el tiempo necesario para que los desarrolladores comprendan todo esto. Aquí es donde se vuelve más difícil. En cualquier caso, 10 años no fueron suficientes para que lo comprendieran. Bueno, hasta entonces no se puede esperar un milagro. No sucederá en forma de una opción de montaje “que usted y yo no conocíamos”, ni en forma de un parche cuya preparación sea “sólo una cuestión de negocios”. Para cada “solución” apresurada presentaré un nuevo escenario de degeneración. Los árboles B son uno de mis temas favoritos y debo decir que estas estructuras no toleran libertades consigo mismas.
¿Cómo posiciono Btrfs por mí mismo? Como algo que en absoluto puede llamarse sistema de archivos, y mucho menos usarse. Porque, por definición, el FS es un subsistema del sistema operativo responsable de la gestión eficaz del recurso "espacio en disco", lo que no vemos en el caso de Btrfs. Pues imagina que viniste a la tienda a comprar un reloj para no llegar tarde al trabajo, y en lugar de un reloj te vendieron una parrilla eléctrica con temporizador de máximo 30 minutos. Entonces, la situación con Btrfs es aún peor.
Al revisar las listas de correo, a menudo me encuentro con la afirmación de que administrar eficazmente el espacio en disco ya no es relevante debido al bajo costo de las unidades. Esto es una completa tontería. Sin un administrador de espacio en disco eficaz, el sistema operativo se volverá vulnerable e inutilizable. Independientemente de la capacidad de los discos de su máquina.
Me gustaría solicitar comentarios sobre la interrupción del soporte de Btrfs en RHEL.
Aquí no hay nada especial que comentar, está todo muy claro. También lo tenían como “avance tecnológico”. Entonces, no pasé por esta "vista previa". ¡No dejes que esta etiqueta cuelgue para siempre! Pero no pueden lanzar un producto defectuoso con soporte completo. RHEL es una empresa, es decir, una relación prescrita entre mercancías y dinero. Red Hat no puede intimidar a los usuarios como lo hacen en la lista de correo de Btrfs. Imagínese la situación: un cliente que pagó el dinero que tanto le costó ganar por el disco y también a usted por su soporte, quiere saber a dónde se fue su espacio en el disco después de no escribir nada. ¿Qué le responderás a esto?
Más. Entre los clientes de Red Hat se incluyen grandes bancos y bolsas de valores de renombre. Imagínese lo que sucedería si estuvieran sujetos a ataques DoS basados en la vulnerabilidad mencionada en Btrfs. ¿Quién crees que es el responsable de esto? A aquellos que estén a punto de señalar con el dedo la línea de la licencia GPL, donde está escrito que el autor no es responsable de nada, les diré inmediatamente: "¡Escóndelo!". Red Hat te responderá, ¡y de tal manera que no te parecerá suficiente! Pero sé que Red Hat no enfrenta este tipo de problema, dado su equipo particularmente sólido de ingenieros de control de calidad con quienes tuve la oportunidad de trabajar estrechamente en mi tiempo.
¿Por qué algunas empresas siguen apoyando a Btrfs en sus productos empresariales?
Tenga en cuenta que el prefijo "empresa" en el nombre del producto no significa mucho. La empresa es una medida de responsabilidad inherente a la relación contractual con el cliente. Sólo conozco una empresa basada en GNU/Linux: RHEL. Todo lo demás, desde mi punto de vista, sólo se presenta como una empresa, pero no lo es. Y finalmente, si hay demanda de algo, siempre habrá oferta (en nuestro caso, este es el mencionado “apoyo”). Hay demanda para absolutamente todo, incl. y software inutilizable. Cómo se forma esa demanda y quién la alimenta es otro tema.
Por lo tanto, no sacaría ninguna conclusión después de que se rumorea que Facebook ha implementado Btrfs en sus servidores. Además, recomendaría mantener cuidadosamente en secreto las direcciones de esos servidores por las razones anteriores.
¿Por qué últimamente se ha puesto tanto esfuerzo en limpiar el código XFS? Después de todo, inicialmente se trata de un sistema de archivos de terceros, y ext4 ha sido estable durante mucho tiempo y tiene continuidad con respecto a versiones anteriores igualmente estables. ¿Qué interés tiene Red Hat en XFS? ¿Tiene sentido desarrollar activamente dos sistemas de archivos que tengan un propósito similar: ext4 y XFS?
No recuerdo qué motivó esto. Es muy posible que la iniciativa proviniera de los clientes de Red Hat. Recuerdo que se llevaron a cabo investigaciones de este tipo: en algunos sistemas de archivos anteriores, se creó una cantidad gigantesca de objetos en unidades de disco de alta gama de nueva generación. Según los resultados, XFS se comportó mejor que ext4. Entonces comenzaron a promocionarlo como el más prometedor. En cualquier caso, no buscaría aquí nada sensacional.
Para mí es como si hubieran sustituido un punzón por jabón. No tiene sentido desarrollar ext4 y XFS. Tanto en paralelo como cualquiera de ellos a elegir. Nada bueno saldrá de esto. Aunque en la naturaleza a menudo hay situaciones en las que hay mucho potencial de crecimiento, pero no hay espacio para crecer. En este caso, surgen varios crecimientos extraños y feos, a los que todos señalan con el dedo (“¡Oh, mira, lo que no verás en esta vida!”).
¿Crees que el problema de la violación de capa se resolvió (en un sentido negativo) con la llegada de funciones de cifrado en ext4, F2FS (sin mencionar RAID en Btrfs)?
En general, la introducción de cualquier nivel y la decisión sobre su no infracción suele ser una cuestión de política, y no me comprometo a comentar nada aquí. Los aspectos objetivos de la violación de la capa son de poco interés para cualquiera, pero podemos considerar algunos de ellos usando el ejemplo de la violación "desde arriba", es decir, la implementación en el FS de la funcionalidad que ya existe en la capa de bloque. Semejante “violación” sólo se justifica con raras excepciones. Para cada uno de estos casos, primero debe demostrar dos cosas: que es realmente necesario y que el diseño del sistema no se verá perjudicado al hacerlo.
Por ejemplo, la duplicación, que tradicionalmente ha sido una actividad para la capa de bloques, tiene sentido implementarla a nivel del sistema de archivos. Por diferentes razones. Por ejemplo, se produce una corrupción “silenciosa” de los datos (bit rot) en las unidades de disco. Esto es cuando el dispositivo funciona correctamente, pero los datos del bloque se dañan inesperadamente bajo la influencia de un cuanto gamma duro emitido por un quásar distante, etc. Lo peor es que este bloque resulte ser un bloque del sistema FS (superbloque, bloque de mapa de bits, nodo del árbol de almacenamiento, etc.), porque esto seguramente provocará un pánico en el kernel.
Tenga en cuenta que los espejos que ofrece la capa de bloque (el llamado RAID 1) no le salvarán de este problema. Bueno, en serio: ¿alguien debería comprobar las sumas de comprobación y leer la réplica en caso de fallo? Además, tiene sentido reflejar no sólo todo, sino sólo los metadatos. Algunos datos importantes (por ejemplo, archivos ejecutables de aplicaciones críticas) se pueden almacenar como metadatos. En este caso, reciben las mismas garantías de seguridad. Tiene sentido confiar la protección de los datos restantes a otros subsistemas (quizás incluso a las aplicaciones del usuario); hemos proporcionado todas las condiciones necesarias para ello.
Estos espejos "económicos" tienen derecho a existir y sólo pueden organizarse eficazmente a nivel del sistema de archivos. De lo contrario, la violación de capas está saturando un subsistema con código duplicado en aras de algunos beneficios microscópicos. Un ejemplo sorprendente de esto es la implementación de RAID-5 utilizando FS. Estas soluciones (RAID/LVM propio en el sistema de archivos) acaban con este último en términos arquitectónicos. También cabe señalar aquí que la infracción de capas es "puesta en marcha" por varios tipos de estafadores de marketing. A falta de ideas, se añaden a los subsistemas funcionalidades implementadas desde hace mucho tiempo en niveles vecinos, lo que se presenta como una nueva característica extremadamente útil y se impulsa activamente.
Reiser4 fue acusado de violar los niveles "desde abajo". Partiendo del hecho de que el sistema de archivos no es monolítico, como todos los demás, sino modular, se asumió sin fundamento que hace lo que debería hacer el nivel superior (VFS).
¿Se puede hablar de la muerte de ReiserFS v3.6 y, por ejemplo, de JFS? Últimamente casi no han recibido atención en el núcleo. ¿Están obsoletos?
Aquí debemos definir qué significa la muerte de un producto de software. Por un lado, se utilizan con éxito (después de todo, para eso fueron creados), lo que significa que viven. Por otro lado, no puedo hablar por JFS (no sé mucho), pero ReiserFS (v3) es muy difícil de adaptar a las nuevas tendencias (probado en la práctica). Esto significa que en el futuro los desarrolladores no prestarán atención a él, sino a aquellos que sean más fáciles de adaptar. Desde este lado resulta que, por desgracia, en términos arquitectónicos está muerto. No manipularía en absoluto el concepto de “moralmente obsoleto”. Se aplica bien, por ejemplo, a un guardarropa, pero no a productos de software. Hay un concepto de inferioridad y superioridad en algo. Puedo decir absolutamente que ReserFS v3 ahora es inferior a Reiser4 en todo, pero en algunos tipos de carga de trabajo es superior a todos los demás FS anteriores.
¿Conoce el desarrollo de FS Tux3 y HAMMER/HAMMER2 (FS para DragonFly BSD)?
Sí sabemos. En Tux3 alguna vez me interesó la tecnología de sus instantáneas (los llamados “punteros de versión”), pero en Reiser4 lo más probable es que tomemos un camino diferente. He estado pensando en admitir instantáneas durante mucho tiempo y aún no he decidido cómo implementarlas para volúmenes simples de Reiser4. El hecho es que la novedosa técnica de contador de referencias “perezosa” propuesta por Ohad Rodeh sólo funciona para árboles B. No los tenemos. Para aquellas estructuras de datos que se utilizan en Reiesr4, los contadores "perezosos" no están definidos; para introducirlos, es necesario resolver ciertos problemas algorítmicos que nadie ha asumido todavía.
Según HAMMER: Leí un artículo del creador. No interesado. De nuevo, árboles B. Esta estructura de datos está irremediablemente desactualizada. Lo abandonamos en el siglo pasado.
¿Cómo evalúa la creciente demanda de FS de clústeres de red como CephFS/GlusterFS/etc? ¿Significa esta demanda un cambio en las prioridades de los desarrolladores hacia los FS de red y una atención insuficiente a los FS locales?
Sí, se ha producido tal cambio de prioridades. El desarrollo de los sistemas de archivos locales se ha estancado. Lamentablemente, hacer algo importante para los volúmenes locales ahora es bastante difícil y no todos pueden hacerlo. Nadie quiere invertir en su desarrollo. Esto es casi lo mismo que pedirle a una organización comercial que asigne dinero para la investigación matemática: sin ningún entusiasmo le preguntarán cómo se puede ganar dinero con un nuevo teorema. Ahora bien, un FS local es algo que aparece mágicamente “listo para usar” y “siempre debería funcionar”, y si no funciona, provoca quejas sin respuesta como: “¡Sí, en qué están pensando!”
De ahí la falta de atención a los SA locales, aunque todavía hay mucho trabajo en esa área. Y sí, todo el mundo ha recurrido al almacenamiento distribuido, que se construye sobre la base de sistemas de archivos locales ya existentes. Está muy de moda ahora. La frase “Big Data” provoca una descarga de adrenalina en muchos, asociándola a conferencias, talleres, grandes salarios, etc.
¿Qué tan razonable es, en principio, implementar el sistema de archivos de red en el espacio del kernel en lugar de en el espacio del usuario?
Un enfoque muy razonable que aún no se ha implementado en ninguna parte. En general, la cuestión de en qué espacio se debe implementar un sistema de archivos de red es un "arma de doble filo". Bueno, veamos un ejemplo. El cliente registró datos en una máquina remota. Cayeron en su caché de páginas en forma de páginas sucias. Este es el trabajo para un sistema de archivos de red de "puerta de enlace delgada" en el espacio del kernel. Entonces el sistema operativo tarde o temprano te pedirá que escribas esas páginas en el disco para liberarlas. Entonces entra en juego el módulo FS de red de reenvío (envío) de IO. Determina a qué máquina servidor (nodo de servidor) irán estas páginas.
Luego, la pila de red toma el control (y, como sabemos, se implementa en el espacio del kernel). A continuación, el nodo del servidor recibe ese paquete con datos o metadatos e indica al módulo de almacenamiento backend (es decir, el FS local que opera en el espacio del kernel) que registre todo este material. Entonces, hemos reducido la pregunta a dónde deberían funcionar los módulos de “envío” y “recepción”. Si alguno de esos módulos se ejecuta en el espacio del usuario, esto conducirá inevitablemente a un cambio de contexto (debido a la necesidad de utilizar servicios del kernel). El número de dichos conmutadores depende de los detalles de implementación.
Si hay muchos conmutadores de este tipo, el rendimiento del almacenamiento (rendimiento de E/S) disminuirá. Si su almacenamiento backend se compone de discos lentos, no notará una caída significativa. Pero si tiene discos rápidos (SSD, NVRAM, etc.), el cambio de contexto ya se convierte en un "cuello de botella" y, al ahorrar en el cambio de contexto, el rendimiento se puede aumentar significativamente. La forma estándar de ahorrar dinero es mover módulos al espacio del kernel. Por ejemplo, descubrimos que mover el servidor 9p de QEMU al kernel en la máquina host triplica el rendimiento de VirtFS.
Esto, por supuesto, no es un FS de red, pero refleja plenamente la esencia de las cosas. La desventaja de esta optimización son los problemas de portabilidad. Para algunos, esto último puede ser fundamental. Por ejemplo, GlusterFS no tiene ningún módulo en el kernel. Gracias a esto, ahora funciona en muchas plataformas, incluido NetBSD.
¿Qué conceptos podrían los SF locales tomar de los de red y viceversa?
Hoy en día, los FS de red, por regla general, tienen complementos sobre los FS locales, por lo que no entiendo muy bien cómo se puede pedir prestado algo de este último. Bueno, efectivamente, consideremos una empresa de 4 empleados, en la que cada uno hace lo suyo: uno distribuye, otro envía, el tercero recibe, el cuarto almacena. Y la pregunta: ¿qué puede pedir prestado la empresa al empleado que lo almacena? Suena un poco incorrecta (lo que podría haberle prestado ya lo tiene desde hace mucho tiempo).
Pero los SF locales tienen mucho que aprender de los de red. En primer lugar, debería aprender de ellos cómo agregar volúmenes lógicos a un alto nivel. Ahora el llamado Los sistemas de archivos locales "avanzados" agregan volúmenes lógicos exclusivamente utilizando tecnología de "dispositivo virtual" tomada de LVM (esa misma violación de capas infecciosas que se implementó por primera vez en ZFS). En otras palabras, la traducción de direcciones virtuales (números de bloque) a direcciones reales y viceversa se produce en un nivel bajo (es decir, después de que el sistema de archivos haya emitido una solicitud de E/S).
Tenga en cuenta que agregar y eliminar dispositivos en volúmenes lógicos (no espejos) dispuestos en la capa de bloque genera problemas sobre los que los proveedores de tales "características" guardan modesto silencio. Me refiero a la fragmentación en dispositivos reales, que puede alcanzar valores monstruosos, mientras que en un dispositivo virtual todo está bien. Sin embargo, pocas personas están interesadas en los dispositivos virtuales: todos están interesados en lo que sucede en sus dispositivos reales. Pero los FS tipo ZFS (así como cualquier FS junto con LVM) funcionan solo con dispositivos de disco virtual (asigne direcciones de disco virtual entre los libres, desfragmente estos dispositivos virtuales, etc.). ¡Y no tienen idea de lo que sucede en los dispositivos reales!
Ahora imagine que no tiene fragmentación en el dispositivo virtual (es decir, solo tiene una extensión gigante viviendo allí), agrega un disco a su volumen lógico y luego elimina otro disco aleatorio de su volumen lógico y luego lo reequilibra. Y tantas veces. No es difícil imaginar que en el dispositivo virtual seguirás viviendo en la misma medida, pero en los dispositivos reales no verás nada bueno.
¡Lo peor es que ni siquiera eres capaz de corregir esta situación! Lo único que puede hacer aquí es pedirle al sistema de archivos que desfragmente el dispositivo virtual. Pero ella te dirá que allí todo es genial: solo hay una extensión, la fragmentación es cero y ¡no puede ser mejor! Por lo tanto, los volúmenes lógicos dispuestos a nivel de bloque no están destinados a la adición o eliminación repetida de dispositivos. En el buen sentido, solo necesita ensamblar un volumen lógico a nivel de bloque una vez, dárselo al sistema de archivos y luego no hacer nada más con él.
Además, la combinación de subsistemas independientes FS+LVM no permite tener en cuenta la diferente naturaleza de las unidades a partir de las cuales se agregan los volúmenes lógicos. De hecho, supongamos que ha ensamblado un volumen lógico a partir de HDD y dispositivos de estado sólido. Pero entonces el primero requerirá desfragmentación y el segundo no. Para este último, es necesario emitir solicitudes de descarte, pero para el primero, no, etc. Sin embargo, en esta combinación es bastante difícil demostrar tal selectividad.
Tenga en cuenta que después de crear su propio LVM en el sistema de archivos, la situación no mejora mucho. Además, al hacer esto, en realidad pone fin a la posibilidad de mejorarlo en el futuro. Esto es muy malo. En la misma máquina pueden coexistir diferentes tipos de unidades. Y si el sistema de archivos no distingue entre ellos, ¿quién lo hará?
Otro problema acecha a los llamados. Sistemas de archivos “Write-Anywhere” (esto también incluye Reiser4, si especificó el modelo transaccional apropiado durante el montaje). Estos sistemas de archivos deben proporcionar herramientas de desfragmentación sin precedentes en su poder. Y el administrador de volumen de bajo nivel no ayuda aquí, solo estorba. El hecho es que con un administrador de este tipo, su FS almacenará un mapa de bloques libres de un solo dispositivo: uno virtual. En consecuencia, solo puedes desfragmentar un dispositivo virtual. Esto significa que su desfragmentador funcionará durante mucho, mucho tiempo en un enorme espacio único de direcciones virtuales.
Y si hay muchos usuarios que realizan sobrescrituras aleatorias, el efecto útil de dicho desfragmentador se reducirá a cero. Su sistema inevitablemente comenzará a ralentizarse y usted sólo tendrá que cruzar las manos ante el decepcionante diagnóstico de "diseño roto". Varios desfragmentadores ejecutándose en el mismo espacio de direcciones sólo interferirán entre sí. Es una cuestión completamente diferente si mantiene su propio mapa de bloques libres para cada dispositivo real. Esto paralelizará efectivamente el proceso de desfragmentación.
Pero esto sólo se puede hacer si tiene un administrador de volúmenes lógicos de alto nivel. Los sistemas de archivos locales con tales administradores no existían anteriormente (al menos, no los conozco). Sólo los sistemas de archivos de red (por ejemplo, GlusterFS) tenían administradores de este tipo. Otro ejemplo muy importante es la utilidad de verificación de integridad del volumen (fsck). Si almacena su propio mapa independiente de bloques libres para cada subvolumen, entonces el procedimiento para verificar un volumen lógico se puede paralelizar de manera efectiva. En otras palabras, los volúmenes lógicos con gerentes de alto nivel escalan mejor.
Además, con los administradores de volumen de bajo nivel no podrá organizar instantáneas completas. Con los sistemas de archivos tipo LVM y ZFS, solo puede tomar instantáneas locales, pero no instantáneas globales. Las instantáneas locales le permiten revertir instantáneamente solo las operaciones de archivos habituales. Y nadie allí revertirá operaciones con volúmenes lógicos (agregar/eliminar dispositivos). Veamos esto con un ejemplo. En algún momento, cuando tienes un volumen lógico de dos dispositivos A y B que contienen 100 archivos, tomas una instantánea del sistema S y luego creas otros cien archivos.
Después de eso, agrega el dispositivo C a su volumen y finalmente revierte su sistema a la instantánea S. Pregunta: ¿Cuántos archivos y dispositivos contiene su volumen lógico después de revertir a S? Habrá 100 archivos, como habrás adivinado, pero habrá 3 dispositivos: estos son los mismos dispositivos A, B y C, aunque en el momento de crear la instantánea solo había dos dispositivos en el sistema (A y B). ). La operación de agregar el dispositivo C no se revirtió, y si ahora elimina el dispositivo C de la computadora, dañará sus datos, por lo que antes de eliminarlo deberá realizar primero una operación costosa para eliminar el dispositivo del volumen lógico de reequilibrio, que dispersará todos los datos del dispositivo C a los dispositivos A y B. Pero si su FS admitiera instantáneas globales, dicho reequilibrio no sería necesario y, después de una reversión instantánea a S, podría eliminar de forma segura el dispositivo C de la computadora.
Por lo tanto, las instantáneas globales son buenas porque le permiten evitar la costosa eliminación (agregación) de un dispositivo de un volumen lógico (a un volumen lógico) con una gran cantidad de datos (por supuesto, si recuerda tomar una "instantánea" de su sistema). en el momento adecuado). Permítame recordarle que crear instantáneas y revertir el sistema de archivos son operaciones instantáneas. Puede surgir la pregunta: ¿cómo es posible revertir instantáneamente una operación en un volumen lógico que le llevó tres días? ¡Pero es posible! Siempre que su sistema de archivos esté diseñado correctamente. Se me ocurrió la idea de estas "instantáneas 3D" hace tres años y el año pasado patenté esta técnica.
Lo siguiente que los FS locales deberían aprender de los de red es a almacenar metadatos en dispositivos separados de la misma manera que los FS de red los almacenan en máquinas separadas (los llamados servidores de metadatos). Hay aplicaciones que funcionan principalmente con metadatos y estas aplicaciones pueden acelerarse enormemente colocando los metadatos en costosos dispositivos de almacenamiento de alto rendimiento. Con la combinación FS+LVM, no podrá demostrar dicha selectividad: LVM no sabe qué hay en el bloque que le pasó (datos allí o metadatos).
No obtendrá muchos beneficios al implementar su propio LVM de bajo nivel en el FS en comparación con la combinación FS+LVM, pero lo que puede hacer muy bien es saturar el FS para que luego sea imposible trabajar con su código. ZFS y Btrfs, que se apresuraron con los dispositivos virtuales, son ejemplos claros de cómo la violación de capas mata el sistema en términos arquitectónicos. Entonces, ¿por qué hago todo esto? Además, no es necesario instalar su propio LVM de bajo nivel en el sistema de archivos. En su lugar, es necesario agregar dispositivos en volúmenes lógicos de alto nivel, como lo hacen algunos sistemas de archivos de red con diferentes máquinas (nodos de almacenamiento). Es cierto que lo hacen de manera repugnante debido al uso de malos algoritmos.
Ejemplos de algoritmos absolutamente terribles son el traductor DHT en el sistema de archivos GlusterFS y el llamado mapa CRUSH en el sistema de archivos Ceph. Ninguno de los algoritmos que vi me satisfizo en términos de simplicidad y buena escalabilidad. Así que tuve que recordar el álgebra e inventarlo todo yo mismo. En 2015, mientras experimentaba con paquetes de funciones hash, se me ocurrió y patenté algo que me conviene. Ahora puedo decir que el intento de poner todo esto en práctica fue un éxito. No veo ningún problema de escalabilidad en el nuevo enfoque.
Sí, cada subvolumen requerirá una estructura separada, como un superbloque en la memoria. ¿Esto da mucho miedo? En general, no sé quién va a "hervir el océano" y crear volúmenes lógicos de cientos de miles o más de dispositivos en una máquina local. Si alguien puede explicarme esto se lo agradeceré mucho. Mientras tanto, para mí esto es una tontería de marketing.
¿Cómo afectaron los cambios en el subsistema de dispositivos de bloques del kernel (por ejemplo, la aparición de blk-mq) a los requisitos para la implementación de FS?
No tuvieron ningún impacto. No sé qué pasaría en la capa de bloques que haría necesario diseñar un nuevo FS. La interfaz de interacción de estos subsistemas es muy pobre. Desde el lado del controlador, el FS solo debería verse afectado por la aparición de nuevos tipos de unidades, a las que se ajustará primero la capa de bloque, y luego el FS (para reiser4 esto significará la aparición de nuevos complementos).
¿La aparición de nuevos tipos de medios (por ejemplo, SMR o la ubicuidad de los SSD) significa desafíos fundamentalmente nuevos para el diseño de sistemas de archivos?
Sí. Y estos son incentivos normales para el desarrollo de los servicios financieros. Los desafíos pueden ser diferentes y completamente inesperados. Por ejemplo, he oído hablar de unidades en las que la velocidad de una operación de E/S depende en gran medida del tamaño de un dato y su desplazamiento. En Linux, donde el tamaño del bloque FS no puede exceder el tamaño de la página, dicha unidad no mostrará todas sus capacidades de forma predeterminada. Sin embargo, si su sistema de archivos está diseñado correctamente, existe la posibilidad de sacarle mucho más provecho.
¿Cuántas personas además de usted trabajan actualmente con el código Reiser4?
Menos de lo que me gustaría, pero tampoco experimento una grave escasez de recursos. Estoy más que satisfecho con el ritmo de desarrollo de Reiser4. No voy a "conducir caballos", esta no es la zona adecuada. Aquí, “¡si conduces más silenciosamente, seguirás adelante!” Un sistema de archivos moderno es el subsistema del núcleo más complejo, cuyas decisiones de diseño incorrectas pueden deshacer años posteriores de trabajo humano.
Al ofrecer voluntarios para implementar algo, siempre garantizo que los esfuerzos ciertamente conducirán al resultado correcto, que puede ser requerido para necesidades graves. Como comprenderá, no puede haber muchas garantías de este tipo a la vez. Al mismo tiempo, no soporto a las "figuras" que promueven descaradamente "características" de software obviamente inutilizable, engañando a cientos de usuarios y desarrolladores, y al mismo tiempo se sientan y sonríen en las cumbres del kernel.
¿Alguna empresa ha expresado su voluntad de apoyar el desarrollo de Reiser4?
Sí, hubo tales propuestas, incl. y de un proveedor importante. Pero para ello tuve que mudarme a otro país. Lamentablemente ya no tengo 30 años, no puedo separarme e irme así al primer pitido.
¿Qué funciones faltan actualmente en Reiser4?
No existe una función de "cambiar tamaño" para volúmenes simples, similar a la que se encuentra en ReiserFS(v3). Además, las operaciones de archivos con el indicador DIRECT_IO no estarían de más. A continuación, me gustaría poder segregar un volumen en “subvolúmenes semánticos”, que no tengan un tamaño fijo y que se puedan montar como volúmenes independientes. Estos problemas son buenos para los principiantes que quieren probar suerte en lo "real".
Y finalmente, me gustaría tener volúmenes lógicos de red con implementación y administración simples (los algoritmos modernos ya lo permiten). Pero lo que Reiser4 definitivamente nunca tendrá es RAID-Z, matorrales, cachés de espacio libre, variables de 128 bits y otras tonterías de marketing que surgieron en el contexto de la escasez de ideas entre los desarrolladores de algunos sistemas de archivos.
¿Se puede implementar todo lo que pueda ser necesario mediante complementos?
Si hablamos sólo en términos de interfaces y complementos (módulos) que las implementan, entonces no todo. Pero si también introduces relaciones en estas interfaces, entonces, entre otras cosas, tendrás los conceptos de polimorfismos superiores, con los que ya podrás arreglártelas. Imagine que hipotéticamente congela un sistema de ejecución orientado a objetos, cambia el valor del puntero de instrucción para que apunte a otro complemento que implemente la misma interfaz X y luego descongela el sistema para que continúe ejecutándose.
Si el usuario final no nota tal “sustitución”, entonces decimos que el sistema tiene polimorfismo de orden cero en la interfaz X (o el sistema es heterogéneo en la interfaz X, que es lo mismo). Si ahora no solo tiene un conjunto de interfaces, sino que también tiene relaciones entre ellas (gráfico de interfaz), entonces puede introducir polimorfismos de orden superior, que caracterizarán la heterogeneidad del sistema que ya se encuentra en la "vecindad" de cualquier interfaz. Introduje esta clasificación hace mucho tiempo, pero, lamentablemente, nunca sucedió.
Entonces, con la ayuda de complementos y polimorfismos superiores, puede describir cualquier característica conocida, así como "predecir" aquellas que nunca se han mencionado. No he podido demostrarlo estrictamente, pero tampoco conozco todavía ningún contraejemplo. En general, esta pregunta me recordó el “Programa Erlangen” de Felix Klein. Hubo un tiempo en que intentó representar toda la geometría como una rama del álgebra (específicamente, la teoría de grupos).
Ahora a la pregunta principal: ¿cómo van las cosas con la promoción de Reiser4 al núcleo principal? ¿Hubo alguna publicación sobre la arquitectura de este sistema de archivos de la que habló en la última entrevista? ¿Qué relevancia tiene esta pregunta desde su punto de vista?
En general, llevamos tres años solicitando la inclusión en la rama principal. El último comentario de Reiser en el hilo público donde se realizó la solicitud de extracción quedó sin respuesta. Así que todas las demás preguntas no son para nosotros. Personalmente, no entiendo por qué necesitamos "fusionarnos" en un sistema operativo específico. En Linux, la luz no convergía como una cuña. Por lo tanto, hay un repositorio separado en el que habrá varios puertos de sucursal para diferentes sistemas operativos. Quien lo necesite podrá clonar el puerto correspondiente y hacer con él lo que quiera (dentro de la licencia, claro). Bueno, si alguien no lo necesita, entonces no es mi problema. En este punto, propongo considerar la cuestión de la “promoción al núcleo principal de Linux” como resuelta.
Las publicaciones sobre arquitectura FS son relevantes, pero hasta ahora sólo he encontrado tiempo para mis nuevos resultados, que considero de mayor prioridad. Otra cosa es que soy matemático, y en matemáticas cualquier publicación es un resumen de teoremas y sus demostraciones. Publicar cualquier cosa allí sin pruebas es señal de mal gusto. Si pruebo o refuto completamente cualquier afirmación sobre la arquitectura del FS, el resultado serán tales montones que será bastante difícil de superar. ¿Quién lo necesita? Probablemente esta sea la razón por la que todo sigue en su forma anterior: el código fuente y los comentarios.
¿Qué hay de nuevo en Reiser4 en los últimos años?
La estabilidad tan esperada finalmente se ha materializado. Uno de los últimos en aparecer fue un error que conducía a directorios “indelebles”. La dificultad era que solo aparecía en el contexto de colisiones de hash de nombres y con una determinada ubicación de los registros de directorio en un nodo de árbol. Sin embargo, todavía no puedo recomendar Reiser4 para producción: para ello es necesario trabajar un poco con la interacción activa con los administradores del sistema de producción.
Finalmente logramos implementar nuestra idea de larga data: diferentes modelos de transacción. Anteriormente, Reiser4 solo ejecutaba un modelo Macdonald-Reiser codificado. Esto creó problemas de diseño. En particular, las instantáneas no son posibles en un modelo transaccional de este tipo: quedarán dañadas por un componente atómico llamado "OVERWRITE SET". Reiser4 actualmente admite tres modelos de transacciones. En uno de ellos (Write-Anywhere), el componente atómico OVERWRITE SET incluye sólo páginas del sistema (imágenes de mapas de bits de disco, etc.), que no se pueden "fotografiar" (el problema del huevo y la gallina).
Así las imágenes ahora se pueden realizar de la mejor manera posible. En otro modelo transaccional, todas las páginas modificadas van sólo al OVERWRITE SET (es decir, es esencialmente un diario puro). Este modelo es para aquellos que se quejaron de la rápida fragmentación de las particiones Reiser4. Ahora, en este modelo, su partición no se fragmentará más rápido que con ReiserFS (v3). Los tres modelos existentes, con algunas reservas, garantizan la atomicidad de las operaciones, pero también pueden ser útiles los modelos con pérdida de atomicidad y que preservan sólo la integridad de la sección. Estos modelos pueden resultar útiles para todo tipo de aplicaciones (bases de datos, etc.) que ya hayan asumido algunas de estas funciones. Es muy fácil agregar estos modelos a Reiser4, pero no lo hice porque nadie me preguntó y yo personalmente no lo necesito.
Aparecieron sumas de verificación de metadatos y recientemente las completé con espejos “económicos” (material aún inestable). Si falla la suma de verificación de cualquier bloque, Reiser4 lee inmediatamente el bloque correspondiente del dispositivo de réplica. Tenga en cuenta que ZFS y Btrfs no pueden hacer esto: el diseño no lo permite. Allí debes ejecutar un proceso especial de escaneo en segundo plano llamado "depuración" y esperar a que llegue al bloque problemático. En sentido figurado, los programadores llaman a estos eventos "muletas".
Y finalmente, han aparecido volúmenes lógicos heterogéneos, que ofrecen todo lo que ZFS, Btrfs, capa de bloque, así como las combinaciones FS+LVM en principio no pueden proporcionar: escalado paralelo, asignador de direcciones de disco O(1), migración de datos transparente entre subvolúmenes. Este último también dispone de una interfaz de usuario. Ahora puede mover fácilmente los datos más recientes a la unidad de mayor rendimiento de su volumen.
Además, es posible eliminar urgentemente cualquier página sucia en dicha unidad, acelerando así significativamente las aplicaciones que a menudo llaman a fsync(2). Observo que la funcionalidad de la capa de bloque, llamada bcache, no proporciona tal libertad de acción en absoluto. Los nuevos volúmenes lógicos se basan en mis algoritmos (hay patentes correspondientes). El software ya es bastante estable, es muy posible probarlo, medir el rendimiento, etc. El único inconveniente es que por ahora es necesario actualizar manualmente la configuración del volumen y almacenarla en algún lugar.
Hasta ahora he podido implementar mis ideas en un 10 por ciento, pero logré lo que consideraba más difícil: conectar volúmenes lógicos con un procedimiento flash que realiza todas las acciones diferidas en reiser4. Todo esto todavía está en la rama experimental "formato41".
¿Reiser4 pasa xfstests?
Al menos así fue para mí cuando estaba preparando el último lanzamiento.
¿Es posible, en principio, hacer de Reiser4 un FS de red (clúster) mediante complementos?
¡Es posible e incluso necesario! Si crea un archivo de red basado en un sistema de archivos local diseñado correctamente, ¡el resultado será impresionante! En los FS de red modernos, no estoy satisfecho con la presencia de un nivel de almacenamiento de backend, que se implementa utilizando cualquier FS local. La existencia de este nivel está completamente injustificada. ¡El FS de la red debe interactuar directamente con la capa de bloque y no pedirle al FS local que cree ningún otro archivo de servicio!
En general, dividir los sistemas de archivos en locales y en red es maligno. Surgió de la imperfección de los algoritmos que se utilizaron hace treinta años y para los cuales todavía no se ha propuesto nada. Esta es también la razón de la aparición de una gran cantidad de componentes de software innecesarios (diversos servicios, etc.). En el buen sentido, debería haber solo un FS en forma de módulo de kernel y un conjunto de utilidades de usuario instalado en cada máquina: un nodo de clúster. Este FS es tanto local como de red. ¡Y nada más!
Si nada funciona con Reiser4 en Linux, me gustaría ofrecer un FS para FreeBSD (cita de una entrevista anterior: “...FreeBSD... tiene raíces académicas... Y esto significa que con un alto grado de probabilidad encontrará un lenguaje común con los desarrolladores”) ?
Entonces, como acabamos de descubrir, todo ya funcionó perfectamente con Linux: hay un puerto Reiser4 que funciona por separado en forma de una rama maestra de nuestro repositorio. ¡No me he olvidado de FreeBSD! ¡Oferta! Estoy dispuesto a trabajar estrechamente con quienes conocen bien el interior de FreeBSD. Por cierto: lo que realmente me gusta de su comunidad es que las decisiones las toma un consejo actualizado de expertos independientes, lo que no tiene nada que ver con el engaño del gobierno a una persona permanente.
¿Cómo valora a la comunidad de usuarios de Linux en la actualidad? ¿Se ha vuelto más “pop”?
Dada la naturaleza de mi trabajo, me resulta bastante difícil evaluar esto. La mayoría de los usuarios acuden a mí con informes de errores y solicitudes para corregir la sección. Usuarios como usuarios. Algunos son más inteligentes, otros menos. A todos se les trata igual. Bueno, si el usuario ignora mis instrucciones, entonces disculpe: la orden de ignorar también será ingresada por mi parte.
¿Es posible predecir el desarrollo de los sistemas de archivos durante los próximos cinco a diez años? ¿Cuáles cree que son los principales desafíos que pueden enfrentar los desarrolladores de FS?
Sí, no es difícil hacer tal pronóstico. Hace mucho tiempo que no se desarrollan sistemas de archivos en sentido ascendente. Sólo se crea la apariencia de tal. Los desarrolladores de sistemas de archivos locales se toparon con problemas asociados con un diseño deficiente. Es necesario hacer una advertencia aquí. No considero que el llamado "almacenamiento", "lamido" y portabilidad de código sea desarrollo y desarrollo. Y no clasifico el malentendido llamado “Btrfs” como un desarrollo por las razones que ya he explicado.
Cada parche sólo empeora los problemas. Bien. y siempre hay varios tipos de “evangelistas” para quienes “todo funciona”. Básicamente se trata de escolares y estudiantes que faltan a clases. Imagínese: a él le funciona, pero al profesor no. ¡Qué descarga de adrenalina es esta! Desde mi punto de vista, el mayor daño lo causan los "artesanos" que se apresuraron a "atornillar" con entusiasmo las maravillosas funciones de Btrfs en todo tipo de capas como systemd, docker, etc. - Esto ya se parece a las metástasis.
Intentemos ahora hacer una previsión para cinco o diez años. Ya he enumerado brevemente lo que haremos en Reiser4. El principal desafío para los desarrolladores locales de FS desde arriba será (sí, ya lo ha sido) la incapacidad de hacer un trabajo decente por un salario. Sin ninguna idea en el campo del almacenamiento de datos, seguirán intentando parchear estos desafortunados VFS, XFS y ext4. En este contexto, la situación con VFS parece especialmente cómica, que recuerda a la frenética modernización de un restaurante en el que no hay chefs y no se espera que haya chefs.
Ahora el código VFS, sin condiciones, bloquea varias páginas de memoria al mismo tiempo e invita al FS subyacente a operar en ellas. Esto se introdujo para mejorar el rendimiento de Ext4 en las operaciones de eliminación, pero como es fácil de entender, dicho bloqueo simultáneo es completamente incompatible con los modelos de transacciones avanzados. Es decir, no podrá simplemente agregar soporte para algún sistema de archivos inteligente en el kernel. No sé cuál es la situación en otras áreas de Linux, pero en lo que respecta a los sistemas de archivos, es poco probable que cualquier desarrollo aquí sea compatible con la política seguida por Torvalds en la práctica (los proyectos académicos son expulsados y los estafadores que No tengo idea de lo que es un árbol B, se emiten créditos de confianza interminables). Por lo tanto, se fijó el rumbo hacia una lenta decadencia. Por supuesto, intentarán con todas sus fuerzas hacer pasar esto como “desarrollo”.
Además, los "custodios" de los sistemas de archivos, al darse cuenta de que no se puede ganar mucho solo con el "almacenamiento", intentarán hacer un negocio más rentable. Se trata, por regla general, de sistemas de archivos distribuidos y virtualización. Quizás trasladen el moderno ZFS a algún otro lugar donde aún no exista. Pero, como todos los FS anteriores, se parece a un árbol de Año Nuevo: si puedes colgar otras cosas pequeñas encima, no podrás profundizar más. Admito que es posible construir un sistema empresarial serio basado en ZFS, pero como ahora estamos discutiendo el futuro, solo puedo afirmar con tristeza que ZFS no tiene remedio en este sentido: con sus dispositivos virtuales, los chicos han cortado el oxígeno. para ellos mismos y para las generaciones futuras para un mayor desarrollo. ZFS es cosa del pasado. Y ext4 y XFS ni siquiera son anteayer.
Vale la pena mencionar por separado el sensacional concepto de "sistema de archivos Linux de próxima generación". Este es un proyecto completamente político y de marketing creado para tener la oportunidad, por así decirlo, de "fijar el futuro de los sistemas de archivos" en Linux detrás de personajes específicos. El hecho es que Linux solía ser "sólo por diversión". Pero ahora es principalmente una máquina de hacer dinero. Están hechos en todo lo posible. Por ejemplo, es muy difícil crear un buen producto de software, pero los "desarrolladores" inteligentes se han dado cuenta desde hace tiempo de que no hay necesidad de esforzarse en absoluto: se puede vender con éxito software inexistente que se ha anunciado y promocionado en todo tipo de público. eventos: lo principal es que las diapositivas de la presentación deben contener más "características".
Los sistemas de archivos son perfectos para esto, porque puedes negociar con seguridad durante diez años el resultado. Bueno, si alguien más tarde se queja de la falta de este resultado, ¡simplemente no entiende nada sobre sistemas de archivos! Esto recuerda a una pirámide financiera: en la cima están los aventureros que iniciaron este lío, y los pocos que tuvieron “suerte”: “retiraron dividendos”, es decir. recibió dinero para el desarrollo, consiguió un trabajo bien remunerado como gerente, "apareció" en conferencias, etc.
Luego vienen los que tienen “mala suerte”: contarán las pérdidas, afrontarán las consecuencias de implementar un producto de software inutilizable en producción, etc. Hay muchos más de ellos. Bueno, en la base de la pirámide hay una gran masa de desarrolladores que "cortan" código inútil. Ellos son los mayores perdedores, porque el tiempo perdido no se puede recuperar. Estas pirámides son extremadamente beneficiosas para Torvalds y sus asociados. Y cuantas más pirámides haya, mejor para ellos. Para alimentar tales pirámides, se puede introducir cualquier cosa en el núcleo. Eso sí, en público dicen todo lo contrario. Pero no juzgo por palabras sino por acciones.
Así, “el futuro de los sistemas de archivos en Linux” es otro software muy promocionado, pero difícilmente utilizable. Después de Btrfs, con una alta probabilidad, el lugar de tal "futuro" lo ocupará Bcachefs, que es otro intento de cruzar la capa de bloques de Linux con un sistema de archivos (un mal ejemplo es contagioso). Y lo típico: existen los mismos problemas que en Btrfs. Lo sospeché durante mucho tiempo y luego, de alguna manera, no pude resistirme y miré el código: ¡es cierto!
Los autores de Bcachefs y Btrfs, al crear su FS, utilizaron activamente fuentes de otras personas y entendían poco sobre ellas. La situación recuerda mucho al juego infantil "teléfono roto". Y puedo imaginarme aproximadamente cómo se incluirá este código en el kernel. En realidad, nadie verá los "rastrillos" (todos los pisarán más tarde). Después de numerosas objeciones sobre el estilo del código, acusaciones de violaciones inexistentes, etc., se llegará a una conclusión sobre la "lealtad" del autor, qué tan bien "interactúa" con otros desarrolladores y con qué éxito puede lograrse todo esto. luego ser vendido a corporaciones.
El resultado final no interesará a nadie. Hace veinte años quizás me habría interesado, pero ahora las preguntas se plantean de otra manera: ¿será posible promover esto para que determinadas personas consigan empleo en los próximos diez años? Y, lamentablemente, no es costumbre preguntarse por el resultado final.
En general, desaconsejaría encarecidamente empezar a reinventar su sistema de archivos desde cero. Porque ni siquiera unas inversiones financieras importantes serán suficientes para conseguir algo competitivo en diez años. Por supuesto, me refiero a proyectos serios, y no a aquellos que están destinados a ser "insertados" en el núcleo. Entonces, una forma más efectiva de expresarse es unirse a desarrollos reales, como nosotros. Esto, por supuesto, no es fácil de hacer, pero lo mismo ocurre con cualquier proyecto de alto nivel.
Primero, deberá superar usted mismo el problema que le ofreceré. Después de lo cual, convencido de la seriedad de tus intenciones, comenzaré a ayudarte. Tradicionalmente utilizamos únicamente nuestros propios desarrollos. Las excepciones son los algoritmos de compresión y algunas funciones hash. No enviamos desarrolladores a viajar a conferencias y luego no nos sentamos y combinamos las ideas de otras personas (“tal vez qué sucederá”), como es habitual en la mayoría de las startups.
Desarrollamos todos los algoritmos nosotros mismos. Actualmente estoy interesado en los aspectos algebraicos y combinatorios de la ciencia del almacenamiento de datos. En particular, campos finitos, asintóticas, prueba de desigualdades. También hay trabajo para programadores comunes, pero debo advertirles de inmediato: se ignoran todas las sugerencias de "mirar otro FS y hacer lo mismo". Allí también se incluirán parches destinados a una mayor integración con Linux a través de VFS.
Por lo tanto, no tenemos un rastrillo, pero entendemos hacia dónde debemos movernos y tenemos confianza en que esta dirección es la correcta. Esta comprensión no vino en forma de maná del cielo. Permítanme recordarles que tenemos a nuestras espaldas 29 años de experiencia en desarrollo, dos sistemas de archivos escritos desde cero. Y la misma cantidad de utilidades de recuperación de datos. ¡Y esto es mucho!
Fuente: opennet.ru