Anteriores:
< Trilha Zero >

< BUFFERS >

Lá está você usando um programa e ordena que leia informações do disco. A luzinha do HD pisca, alguma coisa range, a tela muda e, presto! Lá estão elas ao seu dispor. Alguma vez você já pensou no que ocorre durante esses breves momentos? Como o sistema maneja o fluxo de informações entre disco e programa?

Reflita: tudo que depende apenas de mover dados entre circuitos, como transferir informações entre memória e CPU e manipular essas informações, é feito com a rapidez de um raio. Porém, aos olhos do sistema, tudo que depende da movimentação de partes mecânicas parece ocorrer em câmara lenta, mil vezes mais devagar. Exagero? Lembre-se que acesso a memória mede-se em nanossegundos, ou milionésimos de segundos, enquanto acessos a disco são medidos em milissegundos. Mil vezes, pois não? Para ler um dado do disco é preciso localizá-lo, mover a cabeça magnética até a trilha, baixá-la no momento em que ela estiver sobre o setor e somente então lê-lo. E tudo isso toma tempo.

Há programas, como bancos de dados, que freqüentemente necessitam ler informações no disco. Já pensou como seria irritantemente lento se a cada leitura se repetisse todo aquele ritual? Pois para evitar isto o DOS usa um mecanismo engenhoso. Quando um programa requisita alguma informação do disco, o sistema a localiza, lê e armazena em uma região da memória não apenas o dado solicitado, mas todo o setor do disco onde ele se encontra. E, mesmo depois de usada a informação, preserva a imagem do setor na memória. Se o próximo acesso for feito no mesmo setor, o sistema "sabe" que não precisa voltar ao disco: busca o novo dado diretamente da memória. Se não, lê o novo setor em uma nova área, sem apagar o anterior. E assim sucessivamente até que o trecho de memória reservado para este fim esteja cheio. Somente então ele apaga o primeiro setor lido e escreve sobre ele as informações contidas no que acabou de ler. Desta forma há sempre na memória uma imagem dos últimos setores lidos. Qualquer informação requisitada que neles esteja contida dispensa um novo acesso a disco.

Cada área destinada a armazenar um setor é um "buffer". Palavra em inglês que significa armazém (no sentido de "local onde se armazenam coisas"). Pode-se escolher o número de buffers, mas se você não se manifestar, o DOS escolhe um valor default. Nas versões antigas esse número era dois em um XT e três em um AT. Desde a versão 4, depende da memória instalada. Com 640K de memória RAM, o número default é 15. Que, em geral, é pouco. Já pensou como o sistema pode encontrar aquele arquivo que está no subdiretório "pedras" do subdiretório "minerais" do subdiretório "inventario" do subdiretório "dados"? Ele precisa ler para a memória uma imagem de cada diretório para poder achar o caminho das pedras. Com estas imagens nos buffers o próximo arquivo procurado em um desses diretórios é achado quase instantaneamente.

E como aumentar o número de buffers? Ora, com o comando "buffer", é claro. Mas não tente digitá-lo no prompt do DOS. Pois o trecho de memória dedicado aos buffers é encaixado na área de memória ocupada pelo sistema operacional, e isto somente pode ser feito durante a carga do DOS ao se dar a partida na máquina. É por isto que o comando "buffers" somente funciona se incluído no arquivo Config.Sys. Até o DOS 5 sua sintaxe era singela: incluía-se no Config.Sys uma linha com a palavra "buffers", um sinal de igual e o número de buffers desejado. Se você pretende, por exemplo, aumentar o número de buffers para 20, a linha correspondente no Config.Sys fica:

buffers=20

Como você vê, é tudo muito simples. Mas não vá se animar demais e aumentar seus buffers logo para 99, o máximo permitido. Isto, ao invés de ajudar, pode atrapalhar. E por duas razões.

A primeira é que os buffers consomem memória. E, a não ser que você tenha um 386 e um gerenciador de memória estendida como o QEMM386 que pode carregar os buffers nos blocos de memória superior (UMB), eles usam a memória para programas. Cada buffer gasta 532 bytes (os 512 do setor copiado e mais alguns que o sistema usa para identificá-lo). Não parece muito, mas 20 buffers consomem mais de 10K, e os 99 consumiriam 51k. Que podem fazer falta.

A segunda é que com 99 buffers na memória para procurar a informação desejada o DOS pode acabar por demorar mais nessa faina que em um acesso a disco. Na verdade, após determinar o número ideal de buffers para a configuração de sua máquina, aumentar um pouco não melhora muito o desempenho. E aumentar demais piora.

E como achar o número ideal? Bem, depende de fatores diversos: do tipo da máquina, da velocidade de acesso ao disco, da frequência com que os programas usam arquivos e da memória usada por eles. E só há uma forma segura de estabelecê-lo: o velho método do ensaio e erro. Comece em um XT com 10 buffers (com 15 em um AT) e rode os programas que você mais usa. Depois adicione cinco buffers e veja se nota alguma diferença no tempo de acesso a disco. Melhorou? Mais cinco. Até chegar a um ponto onde não haja diferença. O imediatamente anterior é o ideal.

Finalmente, uma advertência. Se algo aqui o fez lembrar de "cache de disco", cuidado. Cache é cache, buffer é buffer. O cache copia na memória tudo que está nas proximidades (e somente o que está nas proximidades) do último setor do disco que foi lido, partindo do princípio que o acesso subsequente se dará nas imediações. Buffers são cópias dos últimos setores acessados (e somente destes, estejam onde estiverem no disco), partindo do princípio que poderão ser novamente acessados. Ambos se baseiam na probabilidade de novo acesso e guardam cópias de setores do disco na memória para acelerar o desempenho do micro, mas a semelhança pára aí. Os buffers são gerenciados pelo DOS e dele fazem parte integrante, enquanto o cache é gerenciado por um programa independente (na verdade um driver) e pode ocupar qualquer área da memória, inclusive da estendida. São coisas distintas.

E justamente aí reside a diferença de sintaxe do comando a partir do DOS 5. Pois esta versão trouxe a possibilidade de usar buffers secundários, que na verdade funcionam como cache de disco: põe-se uma vírgula após o número de buffers primários e se inclui o número desejado de buffers secundários. Mas isto não é obrigatório e o melhor é simplesmente ignorá-lo, pois a serventia é pouca: vai-se gastar memória preciosa para instalar um cache pequeno que pode ser substituído com vantagem por um cache "de verdade", como o Smartdrv.Sys do próprio DOS, que usa a estendida. E até segunda, quando vamos examinar o comando files.

B. Piropo