FreeBSD Handbook/Administração/Configuração e Ajuste/Ajustando Discos

11.12 Ajustando Discos

11.12.1 Variáveis sysctl

11.12.1.1 vfs.vmiodirenable

A variável sysctl vfs.vmiodirenable pode ser definida como 0 (desligado) ou 1 (ligado), onde o padrão é 1. Esta variável controla como os diretórios são armazenados pelo sistema. A maioria dos diretórios são pequenos, utilizando apenas um fragmento (tipicamente 1 K) no sistema de arquivos e inferior (tipicamente 512 bytes) no cache do buffer. Com esta variável desligado (a 0), o cache de buffer armazena somente um número fixo de diretórios mesmo se você tiver uma enorme quantidade de memória. Quando ligado (a 1), este sysctl permite que o cache de buffer utilize a VM Page Cache para cachear os diretórios, fazendo com que toda a memória disponível para cache de diretórios. Entretanto, o mínimo de memória usada para cachear um diretório é o tamanho da página física (tipicamente 4 K) ao invés de 512 bytes. É recomendável manter esta opção se você está executando os serviços que manipulam um grande número de arquivos. Tais serviços podem incluir caches web, grandes sistemas de correio, e os sistemas de notícias. Mantendo esta opção, não vai reduzir o desempenho geral, mesmo com a memória desperdiçada, mas você deve experimentar para descobrir.

11.12.1.2 vfs.write_behind

O vfs.write_behind sysctl padrão da variável para 1 (no). Isso informa o sistema de arquivos para uma escrita como clusters completos são coletados, o que normalmente ocorre com a escrita de grandes arquivos sequenciais. A idéia é evitar a saturação do cache do buffer com buffers sujos quando isto não iria beneficiar o desempenho de I / O. No entanto, este pode parar os processos e, em certas circunstâncias você pode desejar desativá-la.

11.12.1.3 vfs.hirunningspace

A variável sysctl vfs.hirunningspace determina a quantidade de gravação pendente I/O podem ser enfileiradas em sistema de escala de controladores de disco em qualquer ocasião. O padrão normalmente é suficiente, mas em máquinas com muitos discos que você pode querer aumentar até quatro ou cinco megabytes. Note que a fixação de um valor alto demais (superior a cache de buffer do limite de gravação) pode levar a péssima performance de clustering. Não defina este valor arbitrariamente alto! Valores altos de escrita podem adicionar latência em leituras ocorridas no mesmo tempo.

Existem vários outros buffer-cache e cache VM Page sysctls relacionados. Não recomendamos a alteração destes valores, o sistema VM realiza um excelente trabalho ajustando-se automaticamente.

11.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 que entram e saem do sistema e muitos processos ociosos. Tais sistemas tendem a gerar uma grande pressão contínua sobre as reservas de memória livre. Passando esta característica e ajustar a histerese swapout (em segundos desocupado) via vm.swap_idle_threshold1 e vm.swap_idle_threshold2 permite diminuir a prioridade das páginas de memória associadas à processos ociosos mais rapidamente, em seguida, o algoritmo pageout. Isto dá uma mãozinha para o daemon pageout. Não vire esta opção a menos que você precise, pois a troca que você está fazendo é essencialmente pré-memória de páginas, mais cedo ou mais tarde, consumindo mais swap e banda de disco. Em um sistema pequeno esta opção terá um efeito determinável, mas em um grande sistema que já está fazendo uma paginação moderada esta opção permite ao sistema VM uma fase de processos que entram e saem facilmente da memória.

11.12.1.5 hw.ata.wc

FreeBSD 4.3 flertou com o desligamento IDE cache de gravação. Esta reduzida largura de banda para gravar discos IDE, mas foi considerado necessário devido a graves problemas de consistência dos dados introduzidos pelos vendedores de disco rígido. O problema é que discos IDE mentem quando uma gravação completa. IDE com cache de gravação ativado, discos rígidos IDE, não só grava dados fora de ordem no disco, mas às vezes demora a escrever alguns blocos indefinidamente quando está sob cargas pesadas do disco. Uma falha ou falta de energia pode causar graves danos no sistema de arquivos. Padrão do FreeBSD foi modificado para ser seguro. Infelizmente, o resultado foi como uma enorme perda de desempenho que nós mudamos de volta para o cache de gravação ativado por padrão após a liberação. Você deve verificar o padrão no sistema, observando a variável hw.ata.wc sysctl. Se IDE cache de gravação é desligado, você pode ligá-lo novamente, definindo a variável do kernel para 1. Isso deve ser feito a partir do gerenciador de inicialização durante o boot. Depois o kernel não terá nenhum efeito.

Para obter mais informações, consulte ATA(4).

11.12.1.6 SCSI_DELAY (kern.cam.scsi_delay)

A configuração do kernel SCSI_DELAY pode ser utilizada para reduzir o tempo de inicialização do sistema. Os padrões são bastante elevados e podem ser responsáveis por 15 segundos de atraso no processo de inicialização. Reduzir para 5 segundos funciona bem (especialmente com unidades modernas). As versões mais recentes do FreeBSD (5.0 e superior) devem usar o tempo de inicialização kern.cam.scsi_delay ajustável. As opções de configuração de kernel e ajuste de variável aceitam valores em milisegundos e não em segundos.

11.12.2 Soft Updates

O tunefs (8) é um programa pode ser usado para aperfeiçoar um sistema de arquivos. Este programa tem muitas opções diferentes, mas por agora estamos apenas preocupados com alternância Soft Updates on e off, que é feita através de:

# tunefs -n enable /filesystem # tunefs -n disable /filesystem

Um sistema de arquivos não pode ser modificado com tunefs (8) enquanto ele estiver montado. Um bom momento para habilitar o Soft Updates é antes de todas as partições foram montadas, no modo de mono-usuário.

O Soft Updates melhora drasticamente a performance do meta-dados, principalmente a criação do arquivo e eliminação, através do uso de um cache de memória. Nós recomendamos o uso do Soft Updates em todos os seus sistemas de arquivos.

Há dois aspectos negativos para Soft Updates que você deve estar ciente: Primeiro, o Soft Updates garante a consistência do sistema de arquivos no caso de um acidente, mas poderia muito facilmente ser de vários segundos (um minuto sequer!) atualizando o disco físico. Se o sistema falhar você pode perder mais dados do que da outra maneira. Em segundo lugar, o Soft Updates atrasa a liberação de blocos de arquivos. Se você tem um sistema de arquivos (como o sistema de arquivos raiz), que está quase cheio, realizando uma grande atualização, make installworld, pode fazer com que o sistema de arquivos fique sem espaço e que a atualização falhe.

11.12.2.1 Mais detalhes sobre o Soft Updates

Há duas maneiras tradicionais de escrever um arquivo de sistemas de meta-dados de volta para o disco. (Meta-atualizações de dados são alterações de dados não-conteúdo, como inodos e diretórios).

Historicamente, o comportamento padrão era para escrever atualizações de meta-dados de forma síncrona. Se um diretório foi alterado, o sistema esperou até que a mudança fosse realmente gravada no disco. Os buffers de dados de arquivo ( conteúdo do arquivo) foram passados através do buffer cache e backup em disco, mais tarde, de forma assíncrona. A vantagem desta aplicação é que ela opera de forma segura. Se houver uma falha durante uma atualização, os meta-dados estão sempre em um estado consistente. Um arquivo é criado completamente ou não em todos. Se os blocos de dados de um arquivo não encontrarem o seu caminho fora do cache do buffer para o disco, no momento do acidente, fsck (8) é capaz de reconhecer e reparar o sistema de arquivos, definindo o tamanho do arquivo a 0. Além disso, a implementação é clara e simples. A desvantagem é que nos meta-dados mudanças são lentas. Um rm-r, por exemplo, toca 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. Isso inclui atualizações para o diretório em si, a tabela de inodo e, possivelmente, para os blocos indiretos alocados pelo arquivo. O mesmo se aplica para o desenrolar de hierarquias grandes (tar-x).

O segundo caso é a atualização assíncrona dos meta-dados. Este é o padrão para Linux/ext2fs e mount-o async para * BSD UFS. Todas as atualizações de meta-dados são simplesmente passadas pelo cache de buffer também, isto é, eles serão misturados com as atualizações dos dados de conteúdo do arquivo. A vantagem desta aplicação é que não há necessidade de esperar até que cada atualização de meta-dados tenha sido gravada no disco, já que todas as operações que provocam grande quantidade de atualizações de meta-dados trabalham muito mais rápido do que no caso síncrono. Além disso, a implementação ainda é clara e simples, possuindo um baixo risco de falhas no código. A desvantagem é que não há nenhuma garantia para um estado consistente do sistema de arquivos. Se houver uma falha durante uma operação que atualizou grandes quantidades de meta-dados (como uma falha de energia, ou alguém pressionar o botão de reset), o sistema de arquivos ficará em um estado imprevisível. Não há oportunidade para examinar o estado do sistema de arquivos, pois quando o sistema chega-se novamente, os blocos de dados de um arquivo já poderiam ter sido escritos para o disco, enquanto as atualizações da tabela de inodo ou o diretório associado, não. É realmente impossível implementar um fsck que é capaz de limpar todo o caos resultante (porque a informação necessária não está disponível no disco). Se o sistema de arquivos foi danificado além do reparo, a única opção é usar newfs (8) sobre ela e restaurá-lo a partir do backup.

A solução usual para este problema foi implementar a região suja de logging, que também é referido como journaling, embora esse termo não seja usado consistentemente ,ele é ocasionalmente aplicado a outras formas de transação de logging. As atualizações de meta-dados ainda são escritas sincronamente, mas apenas em uma pequena região do disco. Mais tarde, elas serão movidas para a sua localização adequada. Como a área de logging é uma região pequena e contígua no disco, não há distâncias para o disco de cabeça para se mover, mesmo durante operações pesadas, portanto, essas operações são mais rápidas do que as atualizações síncronas. Além da complexidade da aplicação ser bastante limitada, já que o risco de falhas na codificação é baixo. Uma desvantagem é que todos os meta-dados são escritos duas vezes (uma para a região de logging e uma vez para o local adequado),resultando numa perda de desempenho. Por outro lado, no caso de um acidente, todos os meta-dados pendentes podem ser,rapidamente, operações desfeitas ou completadas da área de logging. Após, o sistema vem novamente, resultando em um sistema de arquivos de inicialização rápida.

Kirk McKusick, desenvolvedor do Berkeley FFS, resolveu este problema com o Soft Updates: todas as atualizações de meta-dados pendentes são mantidas na memória e escritas no disco em uma seqüência ordenada ( "ordered meta-data updates"). Isto tem o efeito que, em caso de operações pesadas de meta-dados, as atualizações posteriores para um item de "pegar" os anteriores, se os mais antigos ainda estão na memória e não tenham sido gravados no disco. Assim, todas as operações em, digamos, um diretório, geralmente são feitas em memória antes da atualização ser gravada no disco (os blocos de dados são classificados de acordo com sua posição de modo que eles não vão estar no disco antes de seus meta-dados). Se o sistema falhar, isso causa um rewind log implícito ": todas as operações que não encontrou seu caminho para o disco aparecem como se nunca tivessem acontecido. Um estado consistente de sistema de arquivos é mantido, parecendo ser a de 30 a 60 segundos mais cedo. O algoritmo utilizado garante que todos os recursos em uso são marcadas como tais em seus mapas de bits apropriados: blocos e inodos. Após um acidente, o único erro de alocação de recursos que ocorre é que os recursos são marcados como "used" que, na verdade, são "free". O fsck (8) reconhece esta situação, e libera os recursos que não são mais usados. É seguro ignorar o estado sujo do sistema de arquivos depois de uma pane forçando montá-lo com mount-f. A fim de liberar recursos que podem ser utilizados, fsck (8) precisa ser executado em um momento posterior. Esta é a idéia por trás do background fsck: no momento da inicialização do sistema, apenas um snapshot do sistema de arquivos é gravado. O fsck pode ser executado posteriormente. Todos os sistemas de arquivos podem ser montados "sujos", para que o sistema proceda a inicialização no modo multiusuário. Então, fsck em segundo plano será agendado para todos os sistemas de arquivo onde este for necessário, liberando recursos que podem ser utilizados. (Sistemas de arquivos que não usam o Soft Updates ainda precisa do fsck em primeiro plano no entanto.)

A vantagem é que as operações de meta-dados são quase tão rápidas como atualizações assíncronas (isto é ,mais rápido do que com logging, que tem que escrever os meta-dados duas vezes). As desvantagens são a complexidade do código (implicando um maior risco de erros em uma área que é altamente sensível sobre a perda de dados do usuário), e um maior consumo de memória. Além disso, existem algumas peculiaridades que temos que se acostumar. Após um acidente, o estado do sistema parece estar um pouco "antigo". Em situações onde a opção síncrona pode ter causado alguns arquivos de tamanho zero para permanecer após o fsck, estes arquivos não existem em todos os arquivos com Soft Update, pois nem os meta-dados, nem o conteúdo dos arquivos foram gravados no disco. O espaço em disco não é liberado até que as atualizações tenham sido escritas para o disco, que pode ter lugar algum tempo depois de executar o comando rm. Isso pode causar problemas durante a instalação de grandes quantidades de dados em um sistema que não tem espaço livre suficiente para armazenar todos os arquivos duas vezes.