A resposta para isso depende muito do seu caso de uso.
Eu não tenho mais um Raspberry Pi,
mas o que eu costumava ter veio com 512 MB de RAM.
Convenientemente, meu servidor NFS tem o mesmo valor.
Além do NFS, este servidor (como todos os meus outros)
tem um compilador cruzado m68k que vê o uso regular via distcc .
Ele também tem uma sessão GNU screen sempre ativa
anexado à porta serial de outro servidor.
Vamos dar uma olhada em vmstat :
$ vmstat | awk '{ printf "%4s %2s %2s\n", $3, $7, $8 }' | tail -n 2
swpd si so
0 0 0
Neste caso, nenhum valor de swappiness é melhor que qualquer outro, como o sistema nunca troca. Sistemas pequenos e incorporados nem sempre possuem espaço de troca. De Abordagem de Gerenciamento de Memória para Sistemas Embarcados Swapless , um artigo de 2005 no Linux Journal:
The Linux kernel Out of Memory (OOM) killer is not usually invoked on desktop and server computers, because those environments contain sufficient resident memory and swap space, making the OOM condition a rare event. However, swapless embedded systems typically have little main memory and no swap space. In such systems, there is usually no need to allocate a big memory space; nevertheless, even relatively small allocations may eventually trigger the OOM killer.
Em sistemas que adotam essa abordagem, o mesmo se aplica: Como não há espaço de troca, O swappiness não pode afetar a longevidade do seu armazenamento.
Se você estiver usando seu Raspberry Pi mais como um sistema de desktop, talvez executando X e fazendo sequenciamento genético em Python para o seu trabalho de biologia (eu já vi isso feito), então você pode ter algo para se preocupar. Vamos descobrir:
Suponha que você tenha pouca memória e seu swappiness está definido muito alto, para quase exclusivamente paginar a memória do programa e reter o cache de arquivos. Suponha também, para concretude, que você tem um cartão SDHC classe 8 e que tem um tamanho de bloco de 16 kilobyte (bastante baixo).
Em seguida, você pode escrever 8 MB / s ou 512 blocos por segundo. Sem nivelamento de desgaste, e assumindo falha após 100.000 gravações, isso deixa você apenas 195 segundos, ou pouco mais de três minutos, antes do fracasso. Claro, este é o pior cenário possível. Com nivelamento de desgaste, o tempo de falha é mais próximo de 100.000 gravações vezes o número de blocos não utilizados. Digamos que você tenha 1 GB ou 65.536 blocos disponíveis para nivelamento de desgaste. Neste caso, você obtém (aproximadamente) 65.536 vezes esse tempo, ou cerca de 24 anos de troca constante.
Como você provavelmente não estará constantemente trocando por 24 anos, isso provavelmente não será a causa do fim prematuro do flash.
Algo muito mais provável de ser um problema é
o registro de tempos de acesso de arquivos.
Sempre que um arquivo é lido, seu tempo de acesso é atualizado
a menos que o sistema de arquivos esteja montado com a opção noatime .
Isso requer que um bloco seja escrito toda vez que um arquivo for lido .
Registrando sistemas de arquivos como ext3 e ext4 escreva dados extras em um diário no meio sobre cada escrita. Alguns sistemas de arquivos (por exemplo, ext2 ou FFS) não suportam registro no diário. Usando esses sistemas de arquivos (ou desativando o registro em outros) definitivamente melhora a longevidade da mídia flash, mas reduz a confiabilidade dos dados em caso de perda de energia ou remoção de mídia.
Eu não acho que os logs do sistema em geral
contribuir muito para a morte da mídia flash,
como os únicos arquivos no meu /var/log
que mudaram no mês passado
são btmp , wtmp e lastlog .