Burst Buffers, será una de las nuevas características de Reiser5

Hace ya varios meses hablamos aquí en el blog sobre Reiser5, el cual es un sistema de archivos mantenido por Edward Shishkin y el cual se destaca por incluir la innovación en el escalado paralelo, que se lleva a cabo no a nivel de bloque, sino a través del sistema de archivos.

Reiser5 es una versión sustancialmente revisada del sistema de archivos ReiserFS, en la cual se implementa el soporte para volúmenes lógicos escalables paralelos, lo que permite una distribución eficiente de datos a través de un volumen lógico.

Ahora, en noticias mas recientes, Eduard Shishkin anunció nuevas características que se están desarrollando como parte del proyecto Reiser5.

De las innovaciones recientes, se ha observado que el usuario puede agregar un pequeño dispositivo de bloque de alto rendimiento (por ejemplo, NVRAM), llamado disco proxy, a un volumen lógico relativamente grande compuesto por discos de bajo presupuesto. Esto dará la impresión de que todo el volumen está compuesto por los mismos dispositivos de alto rendimiento que el «disco proxy».

El método implementado se basó en una simple observación de que, en la práctica, la escritura en un disco no se realiza constantemente y la curva de carga de E/S tiene una forma de pico. En el intervalo entre tales «picos», siempre existe la oportunidad de volcar datos de un disco proxy sobrescribiendo todos los datos (o solo una parte) en el almacenamiento principal «lento» en segundo plano. Por lo tanto, la unidad proxy siempre está lista para recibir una nueva pieza de datos.

Inicialmente, esta técnica (conocida como Burst Buffers) se originó en el campo de la informática de alto rendimiento (HPC). Pero resultó ser que también demandaba aplicaciones ordinarias, especialmente para aquellas que imponen altas exigencias a la integridad de los datos (por lo general, este es un tipo diferente de base de datos). Dichos cambios se realizan atómicamente por cualquier aplicación en cualquier archivo, a saber:

• Primero se crea un nuevo archivo que contiene los datos modificados;
• Entonces este nuevo archivo se escribe en el disco usando fsync (2);
• Después de eso, el nuevo archivo cambia de nombre al antiguo, lo que libera automáticamente los bloques ocupados por datos antiguos.

Todos estos pasos, en un grado u otro, causan una disminución significativa en el rendimiento en cualquier sistema de archivos. La situación mejora si el nuevo archivo se escribe primero en un dispositivo dedicado de alto rendimiento, que es exactamente lo que sucede en el sistema de archivos Burst Buffers.

En Reiser5, está previsto enviar opcionalmente no solo nuevos bloques lógicos del archivo al disco proxy, sino también todas las páginas sucias en general. Además, no solo páginas con datos, sino también con metadatos, que se registran en los pasos (2) y (3).

Los discos proxy son compatibles en el contexto del trabajo regular con los volúmenes lógicos Reiser5 anunciados a principios de año. Es decir, el sistema agregado «disco proxy – almacenamiento primario» es un volumen lógico ordinario, con la única diferencia de que el disco proxy tiene prioridad sobre otros componentes del volumen en la política de asignación de direcciones de disco.

Agregar un disco proxy a un volumen lógico no va acompañado de ningún reequilibrio de datos, y su eliminación se produce de la misma manera que la eliminación de un disco normal. Todas las operaciones de disco proxy son atómicas.

Después de agregar un disco proxy, la capacidad total del volumen lógico aumenta en la capacidad de este disco.

El disco proxy debe limpiarse periódicamente, es decir volcar datos de él al almacenamiento principal. Después de alcanzar la estabilidad beta de Reiser5, se planea hacer que la limpieza sea automática (estará a cargo de un hilo especial del núcleo). En esta etapa, la responsabilidad de la limpieza recae en el usuario.

Si no hay espacio libre en el disco proxy, todos los datos se escriben automáticamente en el almacenamiento principal. Al mismo tiempo, el rendimiento general del FS se reduce por defecto (debido a la invocación constante del procedimiento de confirmación de todas las transacciones disponibles).

Fuente: https://marc.info