Para mí, descubrir cuál es la mejor opción para el programador de E/S en el kernel fue un desafío. Primero aprendí que es subjetivo y luego depende del sistema de archivos que uses.
Sé que No-opseguramente deberías usarlo para unidades de estado sólido (SSD).
Lo que quiero saber es cuál es la mejor opción para discos duros normales (rotativos) que contienen sistemas de archivos Ext4 y NTFS (estilo MBR).
¿Y GPT o MBR tienen algún efecto en la elección que hago?
Respuesta1
Sé que seguramente deberías usar No-op para unidades de estado sólido o SSD.
No necesariamente. No sé por qué la gente sigue tratando a los SSD como una especie de caso especial en el que no se necesitan los beneficios de otros programadores. Tener discos giratorios simplemente significa que es más importante fusionar las solicitudes. Fusionar solicitudes es solo una de las cosas que hace el programador.
CFQ, Deadline, etc. hacen más que eso. Por ejemplo, CFQ le permite dar prioridad a determinados procesos sobre otros (a través de ionice), mientras que Deadline le ofrece garantías de latencia. Cualquiera de estos puede seguir siendo relevante para los SSD.
Deshacerse de los discos giratorios solo significa que la decisión de su programador probablemente dependerá más de cómo desea dividir el ancho de banda hacia y desde el disco en lugar de simplemente fusionar solicitudes.
EDITAR:También señalaré que en mi sistema las fusiones se pueden desactivar (independientemente del programador) usando el /sys/block/sdXX/queue/nomergessintonizable. La fecha límite también ofrece una opción ajustable para deshabilitar las fusiones frontales.
Lo que quiero saber es cuál es la mejor opción para HDD normal (giratorio) que contiene sistemas de archivos ext4 y NTFS. (estilo MBR).
La elección del programador probablemente no dependa mucho del sistema de archivos que esté utilizando. Los archivos dentados y de uso frecuente terminan en el caché del sistema de archivos de todos modos. De cualquier manera, ninguno de los programadores parece tener características que beneficien a un sistema de archivos (XFS, ext3, ext4+extents, reiserfs, etc.) sobre otro.
NTFS tiende a fragmentarse mucho, por lo que read_ahead_kbprobablemente sea beneficioso uno más pequeño (tienes que jugar con él para ver qué funciona para ti). Básicamente, si se trata de un volumen muy fragmentado, la extracción de los datos vecinos probablemente ahogue el ancho de banda que podría haberse destinado a una solicitud legítima.
Y GPT/MBR no afecta esta decisión en absoluto.