Schedulers: CFQ vs Deadline vs Noop

O CFQ (Completely Fair Queuing) é o scheduler padrão de I/O do Linux desde o kernel 2.6.18 ele é quem coloca as solicitações síncronas enviadas por processos em filas numeradas e aloca o tempo para que cada uma destas filas acessem o disco, controlando entre outras coisas, a prioridade do acesso ao disco e a largura de banda para I/O.

A partir do Kernel 3.1 foi introduzido algumas opções de otimização no CFQ para SSDs e outros drives 'não-rotacionais' ('discos' que não são discos, como memórias flash etc) onde ele detecta este tipo de dispositivo e suporta múltiplos requests por vez e uma profundidade maior da fila. Seu funcionamento padrão em discos comuns é organizar as filas de acordo com setor e proximidade (lembrando que é um disco girando, sendo lido e gravado).

Existe outros schedulers no Linux, como o Deadline e o Noop. Para SSD o CFQ se mostra com o melhor desempenho, sendo este o padrão da maioria das distribuições.

Há na internet diversos artigos onde mostram como alterar o sistema para que use o Deadline em discos não-rotacionais (SSDs), porém não encontrei nenhum argumento que justifique isto.

Neste link há uma comparação dos 3 schedulers no kernel 3.4 usando disco convencional (HDD) e SSD:

• Linux I/O Scheduler Comparison On The Linux 3.4 Desktop - Phoronix

Um dos argumentos é a opção fifo_batch do Deadline que controla o numero de pedido por lotes de solicitações de I/O no disco, com isto ele equilibra as taxas de latência vs transferência, focando a latência (pois o disco está girando e leva em consideração a proximidade do setor), porém ao inverter (já que no SSD não tem disco) você prioriza a taxa de transferência, em tese, melhorando o desempenho. Porém, mesmo assim, em benchmarks que verifiquei, o CFQ continua melhor e o ganho de transferência no Deadline com esta ação não produz uma melhoria visível.

Ou seja: neste quesito, não faça nada.

Journaling

O Journaling cobra um pouco no desempenho, mas isto é um recurso muito importante para a recuperação dos dados em possíveis crashs no sistema.

Aí depende muito de cada um em desativa-lo, eu acho desnecessário (depende muito de qual uso terá este GNU/Linux com SSD).

Se em seu ambiente você terá um disco HD junto com SSD no Linux, você pode configurar para que o sistema use outro device ou partição para o Journal, apontando para uma área do HD (no mkfs.ext4 ao criar a partição do sistema que será instalado no SSD, use a opção '-J' para as configurações do journal, entre elas há um "device=" onde você aponta um outro dispositivo ou partição para usar como Journal, apontando assim, para o HD comum).

Caso mude o journal no ext4, habilite na montagem do SSD, além dos parâmetros já passados, os seguintes: "journal_checksum" e o "journal_async_commit".

Neste quesito é opcional. Muitos o fazem, porém o ganho de vida útil com os atuais SSDs não será perceptível.