¿Cómo funciona la caché de escritura con un sistema de archivos que abarca discos con diferentes velocidades?

En un sistema Linux moderno con múltiples discos y un RAID de software que abarca unidades lentas (HDD) y rápidas (SSD), ¿cómo se almacenan en caché las escrituras en el sistema de archivos?

Para RAID1 md-raid, la matriz se puede configurar con discos como --write-mostlyy lo --write-behindque sugiere que las lecturas se realizan desde el disco más rápido y que las escrituras en el disco más lento pueden retrasarse. Pero, ¿cómo se almacena en caché a nivel de kernel? ¿El núcleo almacena en caché el disco que escribe antes o después de la capa md-raid? Al final de una llamada write (), ¿se garantiza que los datos se escribirán en uno de los no --write-behinddiscos?

Para un btrfsRAID1, ¿cómo se desarrollaría la misma situación? No hay --write-behindfuncionalidad, entonces, ¿se cuentan las páginas sucias a nivel de dispositivo o de sistema de archivos? ¿En qué punto volvería un write ()?

¿Cómo vm.dirty_*ratioafectan los ajustables a estas configuraciones?

El --write-mostly, --write-behindes manejado por el mdconductor interno. mdmantiene los metadatos, como el mapa de bits con intención de escritura (que es obligatorio para la función de escritura diferida) que básicamente registra qué datos se han escrito aún y qué datos aún faltan. Esto es necesario en caso de que haya un evento de pérdida de energía, cuando los datos aún no han llegado a los dispositivos de escritura principal. En ese caso, el área de datos afectada se volverá a sincronizar (en su caso, lea desde SSD, escriba en HDD).

Pero, ¿cómo se almacena en caché a nivel del núcleo?

Para el caso de escritura subyacente, el controlador md básicamente duplica la solicitud de escritura internamente. La solicitud de escritura maestra va a la (s) unidad (es) primaria (s) y le dice a las capas superiores "OK, ya he hecho esto"; la solicitud de escritura copiada se queda para el lado de la mayoría de la escritura de RAID y puede tardar más en completarse, con suerte sin que nadie lo note.

Luego, la capa de incursión toma muchos pasos para asegurarse de que no se leerán datos del dispositivo de escritura, mientras que todavía hay solicitudes de escritura pendiente en la cola. ¿Por qué se leerían los datos de un dispositivo de escritura principalmente? Bueno, el SSD podría haber fallado, así que es todo lo que queda. Es complicado, y la escritura por detrás presenta algunos casos de esquina.

Probablemente por eso solo es compatible con el nivel RAID-1, no con ninguno de los otros. Aunque podría tener sentido en teoría tener SSD esencialmente como RAID-0 y dos HDD de paridad en modo de escritura rezagada, no hay soporte para una RAID-6 de escritura reversa como esa. Es solo RAID-1 y rara vez se usa incluso allí.

Esto no afecta a las otras configuraciones de caché, básicamente al mecanismo de almacenamiento en caché general no le importa en lo más mínimo cómo el mdcontrolador ha implementado las cosas internamente. El caché hace lo suyo y md hace lo suyo. Por lo tanto, una memoria caché del sistema de archivos funciona igual para un sistema de archivos en la parte superior de md frente a un sistema de archivos en la parte superior de una unidad simple. (La realidad es un poco más complicada que eso, pero puedes pensarlo de esta manera).

Para RAID1 md-raid, la matriz se puede configurar con discos como --write-mostlyy lo --write-behindque sugiere que las lecturas se realizan desde el disco más rápido y que las escrituras en el disco más lento pueden retrasarse. Pero, ¿cómo se almacena en caché a nivel de kernel? ¿El núcleo almacena en caché el disco que escribe antes o después de la capa md-raid?

Después, ya que esta característica es específica de md-raid.

Debería pensar en esta característica de md-raid como almacenamiento en búfer, no almacenamiento en caché. Está limitado por la siguiente mdadmopción:

--escribir detrás =

Especifique que el modo de escritura diferida debe estar habilitado (válido solo para RAID1). Si se especifica un argumento, establecerá el número máximo de escrituras pendientes permitidas. El valor predeterminado es 256.

Solo puedo pensar que también está limitado por el núcleo normal y el almacenamiento en búfer de hardware (es decir, si eso es más pequeño). El almacenamiento intermedio normal del núcleo está limitado por nr_requestsy max_hw_sectors_kb. Ver /sys/class/block/$write_behind_device/queue/. Por almacenamiento en búfer de hardware, me refiero a la memoria caché de escritura en la unidad.

Al final de una llamada write (), ¿se garantiza que los datos se escribirán en uno de los no --write-behinddiscos?

Por supuesto, suponiendo que quiere decir que write () estaba en un archivo abierto con O_SYNC / O_DSYNC, o que realmente quería decir write () + fsync (). Si no, no se aplican garantías en absoluto.