Entre para seguir isso  
Seguidores 0

Limites de Capacidade dos Discos Rígidos

        186.232 Visualizações     4 comentários     Tutoriais   

Seu micro não reconhece a capacidade total do seu disco rígido? Aprenda neste tutorial tudo sobre todas as barreiras de capacidade que você pode encontrar na hora de instalar um disco rígido.

Gabriel Torres Editor executivo do Clube do Hardware

Limites da FAT

Nós dissemos que a menor unidade que a controladora do disco rígido consegue acessar é o setor. Quanto a Microsoft criou o DOS, no entanto, eles decidiram que a menor unidade que o sistema operacional poderia acessar não seria o setor, mas sim um grupo de setores que eles chamaram aglomerado (cluster, em inglês).

O sistema operacional precisa de uma tabela listando quais arquivos estão usando quais setores. O problema de acessar cada setor diretamente é que você precisa de uma tabela longa o suficiente para acomodar todos os setores disponíveis no disco rígido e também deixar uma margem para discos rígidos maiores que poderão ser lançados no futuro. Por exemplo, para nosso disco rígido de 250 GB seria necessária uma lista com 488.397.168 entradas. Mesmo no caso do primeiro disco rígido, lançado em 1983, que tinha apenas 5 MB, listar todos os setores ocuparia muito espaço no disco.

As versões do DOS inferiores à 3.0 usavam um sistema chamado FAT-12, significando uma Tabela de Alocação de Arquivos (a tabela que estamos falando) usando entradas de 12 bits e clusters de 4 KB – isto é, em vez de acessar cada setor diretamente o sistema operacional acessa um grupo de oito setores por vez (4 KB / 512 bytes = 8). Com 12 bits você tem 2^12 entradas na tabela mencionada acima, ou seja, 4.096 entradas. Como cada entrada mapeia um cluster de 4 KB, com o sistema FAT-12 poderíamos ter discos rígidos de até 16 MB (4.096 x 4 KB). Como naquela época os discos rígidos eram de 5 MB e 10 MB, este sistema funcionava muito bem. A propósito, o sistema FAT-12 ainda é usado nos disquetes.

Com o DOS 3.x a Microsoft lançou o sistema FAT-16, que na época usava endereçamento de 14 bits (e não de 16 bits como o nome sugere). Com 14 bits o número de entradas na tabela era de 16.384 e o tamanho de cada cluster era de 2 KB (isto é, cara cluster era um grupo de quatro setores). Fazendo as contas você vai descobrir que com o DOS 3.x o sistema operacional poderia reconhecer discos rígidos de até 32 MB (16.384 x 2 KB).

Com o lançamento do DOS 4.0 a Microsoft expandiu o sistema FAT-16 para usar endereçamento de 16 bits, o que significa que haviam 65.536 entradas na tabela. Ainda usando clusters de 2 KB isto permitia ao sistema operacional a reconhecer discos rígidos de até 128 MB.

Com o DOS 5.0 em vez de aumentar o tamanho da FAT a Microsoft decidiu mexer no tamanho dos clusters. Na época se você formatasse seu disco rígido o sistema operacional escolhia o tamanho do cluster de acordo com a capacidade do seu disco rígido (veja a tabela abaixo). Esta versão do DOS, no entanto, permitia clusters de até 8 KB, permitindo o sistema operacional a reconhecer partições de até 512 MB (65.536 x 8 KB).

Tamanho da Partição

Tamanho do Cluster (FAT-16)

Sistema Operacional

Até 128 MB

2 KB

DOS 5.0 e superiores

De 128 MB até 256 MB

4 KB

DOS 5.0 e superiores

De 256 MB até 512 MB

8 KB

DOS 5.0 e superiores

De 512 MB até 1 GB

16 KB

DOS 6.0 e superiores

De 1 GB até 2 GB

32 KB

DOS 6.0 superiores

De 2 GB até 4 GB

64 KB

Apenas o Windows NT

Finalmente com o DOS 6.0 a Microsoft expandiu a tabela acima para permitir clusters de 16 KB e 32 KB, fazendo com que o sistema operacional reconhecesse discos rígidos de até 2 GB (65.536 x 32 KB). Esta é a versão final do FAT-16 que conhecemos hoje e é o mesmo sistema usado na primeira versão do sistema operacional Windows 95. Portanto o sistema de arquivo FAT-16 ainda hoje tem um limite de 2 GB por partição. Isto significa que se você instalar um disco rígido de 4 GB usando o sistema de arquivo FAT-16 você terá que criar duas partições de 2 GB, ou seja, seu disco rígido teria que ser dividido em uma unidade C: de 2 GB e uma unidade D: de 2 GB.

Só para completar, o Windows NT permitia o uso de partições FAT-16 com clusters de 64 KB (veja na tabela acima), porém esta configuração não é suportada por outros sistemas operacionais; partições formatadas com esta configuração não é reconhecida por outros sistemas operacionais.

A Microsoft poderia continuar indefinidamente aumentando o tamanho do cluster em vez de aumentar o número de posições dentro da tabela de alocação, mas isto resultaria em um problema conhecido como desperdício (slack space). Como a menor unidade no disco rígido que o sistema operacional pode acessar é o cluster (e não o setor) cada arquivo quando armazenado no disco rígido precisa ser do tamanho de um múltiplo exato do tamanho do cluster. Por exemplo, em um disco rígido de 2 GB usando FAT-16 um arquivo de 100 KB ocuparia quatro clusters, ou 128 KB, porque o disco rígido está usando clusters de 32 KB (100 KB / 32 KB = 3.125, um valor quebrado, e por isso ele tem que necessariamente usar quatro clusters). Estes 28 KB extras não são usados para nada, é um espaço desperdiçado. Portanto ao usar clusters grandes, muito espaço no disco rígido é desperdiçado simplesmente porque dentro do disco rígido cada arquivo precisa ter um tamanho que é um múltiplo exato do tamanho do cluster sendo utilizado.

Com o Windows 95 OSR2 (lançado em 1996 e que era uma segunda versão melhorada do Windows 95; também conhecida como Windows 95 B) a Microsoft lançou a FAT-32, que se tornou mais conhecida quanto o Windows 98 foi lançado, dois anos depois. Usando endereçamento de 32 bits ela poderia, pelo menos em teoria, acessar discos com até 2 TB acessando setores diretamente em vez de usar clusters, o que eliminaria o problema do desperdício (slack space). O sistema FAT-32, no entanto, continua usando clusters:

Tamanho da Partição

Tamanho do Cluster (FAT-32)

Até 256 MB

Não disponível

De 256 MB até 8 GB

4 KB

De 8 GB até 16 GB

8 KB

De 16 GB até 32 GB

16 KB

De 32 GB até 2 TB *

32 KB

* Em teoria o FAT-32 suporta partições maiores do que 2 TB – por exemplo, até 128 TB se forem usados clusters de 32 KB (2^32 x 32 KB = 128 TB). Porém, devido a uma limitação no setor de boot do disco rígido, que usa uma variável de 32 bits para numerar os setores físicos presentes do disco rígido, o limite prático do FAT-32 é de 2 TB (2^32 x 512 bytes por setor = 2 TB).

Portanto o problema do desperdício (slack space) ainda existe com o FAT-32.

Este não é o único problema. Até mesmo com o sistema FAT-32 o Windows 95 OSR2 não pode acessar partições maiores do que 32 GB e o Windows 98 não pode acessar partições maiores do que 128 GB. O Windows ME não enfrenta esses problemas.

O Windows NT, 2000 e XP (e provavelmente o Vista) não formata partições FAT-32 maiores do que 32 GB, apesar de eles reconhecerem discos rígidos formatados com FAT-32 dentro do Windows ME com até 2 TB.

Outro problema do sistema FAT-32 é que os arquivos não podem ser maiores do que 4 GB. Com as pessoas atualmente editando vídeos de alta definição e até mesmo usuários neófitos editando e gravando seus próprios DVDs, esta é uma baita limitação.

O sistema FAT-32 permite apenas que cada partição contenha 4.194.304 arquivos. Provavelmente você atingirá essa quantidade e o limite acima de qualquer maneira antes do limite máximo do tamanho da partição de 2 TB.

A solução para esses problemas é usar um sistema de arquivos diferente. Se você é um usuário do Windows o sistema de arquivos mais indicado é o NTFS, que é um sistema de arquivo introduzido pelo Windows NT em 1993 e é suportado nativamente pelos sistemas operacionais Windows NT, 2000, XP, 2003 e Vista. Na verdade este é o sistema de arquivo recomendado se você usa um desses sistemas operacionais. Nós falaremos mais sobre o NTFS na próxima página.

A solução para cada um desses limites explicados nesta página é fazer o upgrade do seu sistema operacional para a versão mais nova.

Compartilhar



Entre para seguir isso  
Seguidores 0

Comentários de usuários


Algumas pessoas inclusive assumem erroneamente que o sistema operacional é o grande vilão deste problema, mas a verdade é que os fabricantes dos discos rígidos são os verdadeiros culpados, já que eles anunciam seus produtos com uma capacidade maior do que a sua capacidade real.

Li a explicação que coloca "a culpa" no sistema e, pesquisando, descobri que essa explicação parece ter bastante sentido.

De acordo com o sistema internacional de medidas, 1 GB (gigabyte) = 1 000 000 000 Bytes, ou seja, 10^9 e 1 GiB (gibibyte) = 1 073 741 824 Bytes, ou seja, 2^30.

Quem passou a usar o GB na base 2 foi o sistema, a indústria de hardware manteve-se coerente e continua usando a nomenclatura original.

Bom, resta saber qual das 2 explicações é a correta, alguém sabe?

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

Memórias são vendidas na "base 2", assim como os disquetes menores que 1MiB, e tem uma boa razão para isso, módulos de memória e clusters precisam ter o tamanho sendo uma potência de 2, usar a base 2 quando se fala em bytes acaba sendo mais prático, sempre da número redondo... Depois que resolveram misturar tudo e nasceu o infame disquete de 1.44MB e o SO comedor de bytes.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

Legal gostei das explicações, só achei que ficou devendo uma explicação sobre sistemas de arquivo não windows, como o Riserfs, o ext2 e ext3 que são os mais usados na plataforma linux.

inté+

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites
Li a explicação que coloca "a culpa" no sistema e, pesquisando, descobri que essa explicação parece ter bastante sentido.

De acordo com o sistema internacional de medidas, 1 GB (gigabyte) = 1 000 000 000 Bytes, ou seja, 10^9 e 1 GiB (gibibyte) = 1 073 741 824 Bytes, ou seja, 2^30.

Quem passou a usar o GB na base 2 foi o sistema, a indústria de hardware manteve-se coerente e continua usando a nomenclatura original.

Bom, resta saber qual das 2 explicações é a correta, alguém sabe?

O uso de prefixos K (que não é um prefixo SI, aliás, o prefixo SI é k), M e assemelhados é tão antigo que, no tempo em que começou, se falava K Words, não kiloBytes... e não tem muito a ver com o padrão SI, que nem existia naquela época. É apenas uma convenção.

A razão do uso desses métodos é óbvia: memórias principais, em máquinas de endereçamento binário (praticamente qualquer coisa que não seja um mainframe super-mega-arcaico da "Era UNIVAC") são mais eficientes quando vêm em potências de dois. No início, era costume escrever a capacidade inteira, mas parece (eu não vivi essa época, mas leia alguns PDFs antigos e você vai ver que estou certo) que, quando as capacidades ficaram maiores, o pessoal começou a abreviar... informalmente ou em propagandas, já que as especificações e programas não usavam isso. E abreviaram usando a convenção de que K, depois do número, queria dizer 1024 e, mais tarde, que M nas mesmas condições quer dizer 1048576.

Quando os prefixos SI se tornaram realmente oficiais, os valores de k, M e etc foram fixados em potências de dez. Na época, criou-se uma convenção especial dentro dos sistemas de medida e principalmente da mente dos engenheiros, programadores e usuários: "k quer dizer 1000, mas K com memórias quer dizer 1024." E por aí vai. Isso era normal, e não dava problema, mesmo porque os "usuários" eram programadores experientes, e essas convenções de qualquer modo eram apenas abreviações não-oficiais, que raras vezes saíam da sala de P&D e das revistas técnicas:)...

O mesmo se aplicou ao M e outros, a medida que essas formas foram sendo consideradas verdadeiras normas SI (o que não são). Foi nessa época que se criou as abreviações: KBytes, Kbits e etc, que parecem muito com o padrão SI, e até foram consideradas pelo pessoal do IEEE.

A indústria aberta dos discos rígidos surgiu depois dessas convenções: os primeiros eram parte integrante de uma máquina e não eram considerados em separado, na verdade. Discos rígidos também armazenavam dados, mas no caso da construção deles não há vantagem em se usar potências de dois. No caso do modelo de endereçamento atual, há uma pequena vantagem (que fica menor com os discos rígidos gigantes da atualidade), mas endereçamento de disco rígido é coisa mais ligada ao software, e vê a capacidade real de forma bem abstrata. Quem realmente gosta de binários no caso dos discos rígidos é o pessoal de SOs.

Nesses casos, a maioria escrevia a capacidade por extenso mesmo, mesmo porque esta não era uma potência de nenhum inteiro pequeno, na maior parte dos casos. Só ainda mais tarde, quando as capacidades se tornaram realmente grandes, se começou a arredondar esses valores... em potências de dez. Por quê? Bom, simplesmente porque a capacidade parecia maior. Isso não causava problema, porque todo mundo que lia documentações e propaganda sabia dessa prática, e os SOs rotulavam tudo usando o valor por extenso. Quando (muito mais tarde) os SOs resolveram rotular a coisa usando KBytes, eles usaram a convenção binária da indústria, que era melhor para eles. Apareceram usuário finais, e isso se tornou um problema.

A solução: simples, usar os novos prefixos Kibi, Mibi e por aí vai, que sempre representam potências de dois, e foram inventados para eliminar confusões. E, enquanto se faz isso, bem que se poderia liquidar de vez essa história de "KByte decimal" para discos rígidos e usar apenas os prefixos binários (Kibi, Mibi e etc.) quando o caso se referir a Bytes, seja de memios magnéticos, ópticos ou eletrônicos.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites


Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!


Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.


Entrar agora