Diminuindo a fragmentação com P2P (Transmission e aMule)
Sistemas de arquivos modernos, EXT4, XFS, Btrfs, têm um recurso chamado pré-alocação persistente, que a grosso modo faz o sistema reservar espaço para o arquivo que está sendo criado (mesmo entre reboots, daí o persistente), sem precisar o encher de zeros, como ocorre em sistemas de arquivos obsoletos. Aliado à alocação por extents (grupos de blocos) e alocação atrasada, dá ao kernel a possibilidade de fazer escolhas muito melhores à medida de vai salvando o arquivo no disco, evitando a fragmentação.
Infelizmente é um recurso que necessita adaptações por parte das aplicações. Basicamente significa usar as funções
Já existia há mais tempo a função
O Trasmission possui uma opção oculta relativa à pré-alocação, que fica no arquivo de configuração
Define o tipo de pré-alocação usada.
1: "fast" [arquivo esparso]
2: "full" [
Por padrão é "1". Porém trocar manualmente para "2" não é mais necessário, pois, neste commit (anterior à versão 1.92), os desenvolvedores implementaram uma forma de usar
O aMule ainda não tem um mecanismo automático, porém a opção está disponível na interface, em "Preferências -> Arquivos -> Préalocar espaço em disco para novos arquivos". A última versão, 2.2.6, é necessária, pois as anteriores tinham bugs no uso da função
Resumo: usar EXT4/XFS/Btrfs e conferir se o seu aplicativo P2P está usando pré-alocação persistente.
Infelizmente é um recurso que necessita adaptações por parte das aplicações. Basicamente significa usar as funções
fallocate()
ou fallocate64()
na hora de criar o arquivo. As funções foram adicionadas à versão 2.10, porém fallocate64()
ficou disponível em 32-bit apenas na glibc 2.11. Qualquer distribuição atual usará uma versão igual ou superior a 2.11; logo, não é mais problema.Já existia há mais tempo a função
posix_fallocate()
, porém ela tem a peculiaridade de, em sistemas de arquivos que não suportem pré-alocação persistente (como EXT2/3 e ReiserFS), emular o comportamento enchendo o arquivo de zeros, o que causa lentidão. Por outro lado, fallocate()
e fallocate64()
falham em sistemas de arquivos que não suportam pré-alocação persistente, o que dá aos programadores meio de escolher o melhor modo de alocação de acordo com o que estiver disponível.O Trasmission possui uma opção oculta relativa à pré-alocação, que fica no arquivo de configuração
~/.config/transmission/settings.json
:"preallocation": 1,
Define o tipo de pré-alocação usada.
1: "fast" [arquivo esparso]
2: "full" [
fallocate64()
, com fallback para posix_fallocate()
]Por padrão é "1". Porém trocar manualmente para "2" não é mais necessário, pois, neste commit (anterior à versão 1.92), os desenvolvedores implementaram uma forma de usar
fallocate64()
quando disponível, mesmo o modo de pré-alocação selecionado no arquivo de configuração sendo "1". Então, o Transmission, desde a versão 1.92, já está 100% adaptado à modernidade!O aMule ainda não tem um mecanismo automático, porém a opção está disponível na interface, em "Preferências -> Arquivos -> Préalocar espaço em disco para novos arquivos". A última versão, 2.2.6, é necessária, pois as anteriores tinham bugs no uso da função
fallocate()
.Resumo: usar EXT4/XFS/Btrfs e conferir se o seu aplicativo P2P está usando pré-alocação persistente.
Comentários
Postar um comentário