Para mim, descobrir qual é a melhor escolha para o agendador de E/S no kernel foi um desafio. Primeiro aprendi que é subjetivo e depende do sistema de arquivos que você usa.
Eu sei que você deve usar No-opSolid Sate Drives (SSDs), com certeza.
O que eu quero saber é a melhor escolha para HDDs normais (rotativos) contendo sistemas de arquivos Ext4 e NTFS (estilo MBR).
E o GPT ou o MBR têm algum efeito na escolha que faço?
Responder1
Eu sei que você deve usar o No-op para unidades Solid Sate ou SSDs, com certeza.
Não necessariamente. Não sei por que as pessoas continuam tratando os SSDs como uma espécie de caso especial em que você não precisa dos benefícios de outros agendadores. Ter discos rotativos significa apenas que é mais importante mesclar as solicitações. Mesclar solicitações é apenas uma coisa que o agendador faz.
CFQ, Deadline, etc. fazem mais do que isso. Por exemplo, CFQ permite dar prioridade a processos específicos sobre outros (via ionice), enquanto Deadline oferece garantias de latência. Qualquer um deles ainda pode ser relevante para SSDs.
Livrar-se dos discos rotativos significa apenas que a decisão do agendador provavelmente será mais sobre como você deseja distribuir a largura de banda de e para o disco, em vez de apenas mesclar solicitações.
EDITAR:Também salientarei que no meu sistema as mesclagens podem ser desativadas (independentemente do agendador) usando o /sys/block/sdXX/queue/nomergesarquivo tunable. O prazo também oferece um ajuste para desabilitar mesclagens frontais.
O que eu quero saber é a melhor escolha para HDD normal (rotativo) contendo sistemas de arquivos ext4 e NTFS. (estilo MBR).
A escolha do agendador provavelmente não depende muito do sistema de arquivos que você está usando. dentries e arquivos usados com frequência acabam no cache do sistema de arquivos de qualquer maneira. De qualquer forma, nenhum dos agendadores parece ter recursos que beneficiem um sistema de arquivos (XFS, ext3, ext4+extents, reiserfs, etc) em detrimento de outro.
O NTFS tende a ficar muito fragmentado, portanto, um tamanho menor read_ahead_kbprovavelmente será benéfico (você terá que brincar com ele para ver o que funciona para você). Basicamente, se for um volume altamente fragmentado, extrair os dados vizinhos provavelmente irá sufocar a largura de banda que poderia ter sido usada em uma solicitação legítima.
E o GPT/MBR não afeta em nada esta decisão.