6.12. Ajustando Discos

6.12.1. Variáveis Sysctl

6.12.1.1. vfs.vmiodirenable

A variável sysctl vfs.vmiodirenable pode ser configurada tanto para 0 (desligada) ou 1 (ligada); onde o padrão é 1. Esta variável controla como os diretórios são cacheados pelo sistema. Muitos diretórios são pequenos, utilizando apenas um fragmento (tipicamente 1 K) no sistema de arquivos e menos no cache do buffer (tipicamente 512 bytes). Entretanto, ao operar em modo padrão o cache do buffer irá cachear apenas um número fixo de diretório ainda que você tenha uma grande quantidade de memória. Ligar este sysctl permite que o cache do buffer use o VM Page Cache para cachear os diretórios, fazendo com que toda memória disponível possa ser usada para cachear diretórios. Entretanto, o mínimo de memória usada para cachear um diretório é o tamanho de uma página física (tipicamente 4 K) ao invés de 512 bytes. Recomendamos que esta variável seja ligada se você estiver usando serviços que manipulem um grande número de arquivos. Serviços como web caches, grandes sistemas de correio eletrônico, e sistemas de notícias. Ligar esta variável geralmente não reduzirá a performance, mesmo com a memória desperdiçada, mas você deve tentar para descobrir.

6.12.1.2. vfs.write_behind

A variável sysctl vfs.write_behind possui valor padrão 1 (ligada). Isto diz para que o sistema de arquivos faça uma escrita completa assim que uma seqüência de clusters seja coletada, isto tipicamente ocorre numa escrita de grandes arquivos sequenciais. A idéia é evitar a saturação do cache do buffer com buffers sujos quando isto não beneficiar a performance de E/S. Entretanto, isto pode paralizar processos, e sob algumas circunstâncias você pode querer desligar esta variável.

6.12.1.3. vfs.hirunningspace

A variável sysctl vfs.hirunningspace determina a quantidade excedente de escrita de I/O que pode ser enfileirada nos controladores de disco globais do sistema em qualquer ocasião. O padrão normalmente é suficiente, mas em máquinas com muitos discos você pode querer aumentar para quatro ou cinco megabytes. Note que configurar um valor alto (excedendo o ponto inicial do buffer de escrita do cache) pode levar a uma performance de clustering degradante. Não configure esta variável com um valor arbitrariamente alto! Valores altos de escrita podem adicionar latência em leituras ocorridas simultaneamente.

Existem outras variáveis sysctl de cache de buffer e página VM. Não recomendamos a modificação de seus valores. Assim como no FreeBSD 4.3, o sistema VM realiza um excelente trabalho ajustando-se automaticamente.

6.12.1.4. vm.swap_idle_enabled

A variável sysctl vm.swap_idle_enabled é útil em grandes sistemas multi-usuário onde você tem muitos usuários entrando e saindo do sistema e muitos processos ociosos. Estes sistemas tendem a gerar uma pressão considerável e contínua nas reservas de memória livre. Sintonizar esta característica e ajustar a histeria de swapout (em segundos fora de uso) através de vm.swap_idle_threshold1 e vm.swap_idle_threshold2 permite que você diminua mais rapidamente a prioridade das páginas de memória associadas à processos ociosos do algoritmo padrão de pageout. Isto dá uma ajuda ao daemon de pageout. Não ligue esta opção a menos que você precise, pois a troca que você está fazendo é essencialmente memória de pré-página antes ao invés de tardia; consumindo mais swap e banda de disco. Em um sistema pequeno esta opção terá um efeito determinável, mas em um sistema maior que já está fazendo uma paginação moderada esta opção permite ao sistema VM organizar os processos que entram e saem da memória mais facilmente.

6.12.1.5. hw.ata.wc

O FreeBSD 4.3 flertou com o desligamento do cache de escrita IDE. Isto reduziu a largura de banda de escrita em discos IDE e foi considerado necessário devido a sérias questões de consistência de dados introduzidas pelos fabricantes de discos rígidos. O problema é que discos IDE mentem quando uma escrita é completada. Com o cache de escrita de IDE ligado, estes discos não somente escrevem dados no disco fora de ordem, mas algumas vezes atrasará a escrita de alguns blocos indefinidamente quando estiver sob grande carga. Um problema ou uma falha de energia pode causar corrupções sérias no sistema de arquivos. O padrão do FreeBSD foi modificado para ser seguro. Infelizmente, o resultado foi uma grande perda de performance, e voltamos a ligar o cache de escrita por padrão. Você pode checar o padrão do seu sistema observando a variável sysctl hw.ata.wc. Se o cache de escrita IDE estiver desligado, você pode liga-lo de volta configurando a variável de kernel de volta para 1. Isto deve ser feito pelo carregador de inicialização durante a inicialização. Tentar fazer isso depois da inicialização do kernel não surtirá efeito.

Para mais informações veja ata(4).

6.12.1.6. SCSI_DELAY (kern.cam.scsi_delay)

A configuração de kernel SCSI_DELAY pode ser usada para reduzir o tempo de inicialização. O padrão é um pouco alto e pode ser responsável 15+ segundos de espera no processo de inicialização. Reduzir para 5 segundos funciona bem (especialmente para drives modernos). Versões mais novas do FreeBSD (5.0+) podem ajustar a variável kern.cam.scsi_delay. As opções de configuração de kernel e ajuste de variável aceitam valores em milisegundos e não em seconds.

6.12.2. Soft Updates

O programa tunefs(8) pode ser usado para fazer um ajuste fino no sistema de arquivos. Este programa possui muitas opções, mas por enquanto vamos nos preocupar apenas em ligar e desligar o Soft Upatades da seguinte maneira:

# tunefs -n enable /sistemadearquivos
# tunefs -n disable /sistemadearquivos

Um sistema de arquivos não pode ser modificado com o tunefs(8) enquanto estiver montado. Uma boa hora para habilitar o Soft Updates é antes que qualquer partição seja montada, em modo mono-usuário.

Nota: Assim como no FreeBSD 4.5, é possível habilitar o Soft Updates no momento da criação do sistema de arquivos, através da opção -U do newfs(8).

O Soft Updates melhora drasticamente a performance do meta-dados, principalmente a criação e eliminação de arquivos, através do uso de um cache de memória. Recomendamos o uso do Soft Updates em todos os seus sistemas de arquivos. Existem dois pequenos problemas no seu uso, que você deve estar ciente: Primeiro, o Soft Updates garante a consistência no sistema de arquivos no caso de problemas, mas pode ficar alguns segundos (até mesmo minuto!) atualizando o disco físico em segundo plano. Se seu sistema der problema você pode perder mais dados do que da outra maneira. Segundo, o Soft Updates atrasa a liberação de blocos do sistema de arquivo. Se você possui um sistema de arquivo (como a raíz) que está praticamente lotado, fazer uma atualização geral tipo make installworld, pode fazer com que o sistema de arquivos fique sem espaço e falhe a atualização.

6.12.2.1. Mais detalhes sobre o Soft Updates

Existe duas maneiras tradicionais de escrever meta-dados de sistemas de arquivos de volta para o disco. (Atualização de meta-dados são atualizações para dados que não sejam de conteúdo, como inodos ou diretórios.)

Historicamente, o comportamento padrão era o de escrever atualizações de meta-dados sincronamente. Se um diretório foi modificado, o sistema esperou até que a mudança fosse realmente feita no disco. Os buffers de dados de arquivo (conteúdo do arquivo) foram passados através do buffer de cache e guardados mais tarde em disco assincronamente. A vantagem desta implementação é a segurança na operação. Se existir uma falha durante uma atualização, os meta-dados sempre estarão em um estado consistente. Um arquivo é criado de forma completa ou não de qualquer forma. Se os blocos de dados de um arquivo não encontrar seu caminho do cache de buffer no disco na hora do problema, o fsck(8) será capaz de reconhecer e reparar o sistema de arquivos configurando o tamanho do arquivo para 0. Além disso, a implementação é clara e simples. A desvantagem é que as mudanças de meta-dados são lentas. O comando rm -r, por exemplo, toca em todos os arquivos em um diretório sequencialmente, mas cada mudança de diretório (exclusão de um arquivo) será escrita sincronamente no disco. Isto inclui atualizações no próprio diretório, na tabela de inodo, e possívelmente nos blocos indiretamente alocados pelo arquivo. Considerações similares são aplicáveis no desenrolar de hierarquias grandes (tar -x).

O segundo caso é o de atualizações assíncronas de meta-dados. Isto é o padrão para Linux/ext2fs e mount -o async para ufs nos *BSD. Todas as atualizações de meta-dados são simplesmente passadas pelo cache de buffer também, eles serão misturados com as atualizações de conteúdo de dados de arquivo. A vantagem desta implementação é que não existe a necessidade de esperar até que cada atualização de meta-dados tenha sido escrita em disco, uma vez que todas as operações que causam grandes quantidades de atualização de meta-dados trabalhem mais rápido que no caso síncrono. Além disso, a implementação é simples e limpa, possuindo um baixo risco de falhas na codificação. A desvantagem é que não existe garantia para um estado consistente do sistema de arquivos. Se ocorrer uma falha durante uma operação que atualizou grandes quantidades de meta-dados (como uma falta de energia, ou alguém pressionar o botão de reinicialização), o sistema de arquivos ficará em um estado imprevisível. Não existe uma oportunidade para examinar o estado do sistema de arquivos quando o sistema voltar para o ar novamente; os blocos de dados de um arquivo já podem ter sido escritos no disco enquanto as atualizações na tabela de inodo, ou diretório associado, ainda não foram. Na verdade é impossível implementar um fsck que seja capaz de limpar todo o caos resultante (pelo fato de que a informação necessária não está disponível no disco). Se o sistema de arquivos foi danificado além das possibilidades de reparação, a única escolha é utilizar o newfs(8) e restaurar um backup.

A solução normal para este problema foi a implementação de uma região suja de logging, também conhecida como journaling, embora este termo não seja usado consistentemente e é ocasionalmente aplicado à outras formas de transação de logging. Atualizações de meta-dados ainda são escritas sincronamente, mas apenas em uma pequena região do disco. Posteriormente serão movidos para a localização apropriada. Devido ao pequeno tamanho da área de logging, a região contígua do disco, não existem grandes distâncias a serem percorridas pela cabeça do disco, mesmo durante operações pesadas, fazendo com que estas operações sejam mais rápidas do que as atualizações síncronas. Além disso, a complexidade de implementação é um tanto quanto limitada, fazendo com que o risco de existência de falhas na codificação sejam menores. A desvantagem é que todos os meta-dados são escritos duas vezes (uma vez na região de logging e outra no local apropriado) causando perda de performance em condições normais. Por outro lado, no caso de pane, todas as operações de meta-dados pendentes podem ser rapidamente desfeitas ou completadas da área de logging depois que o sistema retornar ao ar novamente, resultando uma inicialização rápida de sistema de arquivos.

Kirk McKusick, desenvolvedor do Berkeley FFS, resolveu este problema com o Soft Updates: todas as atualizações de meta-dados pendentes são mantidas em memória e escritas no disco numa seqüência ordenada (``ordered meta-data updates''). Isto causa o seguinte efeito, no caso de operações pesadas de meta-dados, atualizações posteriores em um item ``pegam'' as primeiras que ainda estão em memória e não foram escritas no disco. Então todas as operações em, digamos, um diretório, geralmente são feitas em memória antes que a atualização seja escrita no disco (os blocos de dados são ordenado de acordo com seu posicionamento, assim não podem estar no disco antes de seus meta-dados). Se o sistema der pane, a conseqüência será um ``log rewind'': todas as operações que não encontraram seu caminho para o disco parecem nunca ter ocorrido. Um estado consistente de sistema de arquivo é mantido como se fosse de 30 a 60 segundos antes. O algoritmo utilizado garante que todos os recursos em uso sejam marcados com seus mapas de bits apropriados: blocos e inodos. Depois de uma pane, a única alocação de erros de recursos que ocorre são os marcados como ``used'' que na verdade são ``free''. O fsck(8) reconhece esta situação, e libera os recursos que não estejam em uso. É seguro ignorar o estado sujo do sistema de arquivo após uma pane forçando montá-lo com mount -f. Para liberar recursos que podem estar ociosos, o fsck(8) necessita ser executado posteriormente. Esta é a idéia atrás do background fsck: no momento da inicialização do sistema, apenas um snapshot do sistema de arquivo é gravada. O fsck pode ser executado depois. Todos os sistemas de arquivo podem ser montados ``sujos'', para que a inicialização do sistema prossiga em modo multi-usuário. Então o fsck em segundo plano será agendado para ser executado em todos os sistemas de arquivo onde for necessário, para liberar recursos que podem estar ociosos. (Sistemas de arquivos que não usam Soft Updates ainda necessitam do fsck em primeiro plano.)

A vantagem é que as operações de meta-dados são quase tão rápidas quando as atualizações assíncronas (mais rápidas do que com logging, que precisa escrever os meta-dados duas vezes). As desvantagem são a complexidade do código (implicando em um alto rico de falhas de código em uma área extremamente sensível no que diz respeito a perda de dados do usuário), e um alto consumo de memória. Além disso existem algumas peculiaridades que temos que lidar. Depois de uma pane, o estado do sistema de arquivos parece estar algo como ``antigo''. Em situações onde a opção síncrona pode ter causado alguns arquivos de tamanho zero após o fsck, estes arquivos não existem em um sistema de arquivo com Soft Update, pois nem os meta-dados e os conteúdos dos arquivos foram escritos no disco. O espaço em disco não é liberado até que as atualizações tenham sido escritas no disco, que pode acontecer algum tempo depois de executar o comando rm. Isto pode causar problemas ao introduzir grandes quantidades de dados em um sistema de arquivo que não possui espaço livre suficiente para abrigar todos os arquivos duas vezes.

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.