Olhando as variáveis que você configurou, parece que você está preocupado principalmente com o desempenho de gravação e não se preocupa com possíveis perdas de dados devido a falta de energia.
Você só terá a opção de gravações lentas e o uso de um cache de write-back com operações de gravação assíncrona. As operações de gravação síncrona exigem o comprometimento com o disco e não seriam escritas com preguiça - nunca. Seu sistema de arquivos pode estar causando freqüentes limpezas de páginas e gravações síncronas (geralmente devido a journalling, especialmente com ext3 em data = journal mode). Além disso, mesmo os livretos de página "de fundo" interferirão nas leituras sem cache e nas gravações síncronas , diminuindo-os assim.
Em geral, você deve tomar algumas métricas para ver o que está acontecendo - você vê seu processo de cópia colocado no estado "D" esperando que o trabalho de E / S seja executado pelo pdflush? Você vê intensa atividade de gravação síncrona em seus discos?
Se tudo mais falhar, você pode escolher configurar um sistema de arquivos tmpfs explícito para o qual você copia seus backups e apenas sincroniza dados com seus discos após o fato - mesmo usando inotify automaticamente
Para o cache de leitura, as coisas são significativamente mais simples - existe o fcoretools fadvise
utility que tem o% parâmetro--willneed
para avisar ao kernel para carregar o conteúdo do arquivo no cache do buffer.
Editar:
vm.dirty_ratio = 70
This should in theory give us 16GB for caching I/O and wait some minutes until its writing to disk.
Isso não teria influenciado muito seu cenário de teste, mas há um equívoco em sua compreensão. O parâmetro dirty_ratio não é uma porcentagem da memória total do seu sistema, mas sim da memória gratuita do seu sistema.
Há um artigo sobre Ajuste para cargas de gravação pesada com mais detalhes informação.