[FUG-BR] Hd 4Tb
Luiz Otavio O Souza
lists.br em gmail.com
Domingo Janeiro 30 11:58:19 BRST 2011
On Jan 30, 2011, at 2:12 AM, Joao Rocha Braga Filho wrote:
> 2011/1/29 Cleyton Agapito <cragapito em gmail.com>:
>> Em 29 de janeiro de 2011 13:22, Joao Rocha Braga Filho
>> <goffredo em gmail.com> escreveu:
>>> Pensando no limite de 2 TB da MBR, acho que é por isto que não
>>> lançam HD maior que este tamanho.
>> ...
>>
>> Como a lista é sobre FreeBSD me permiti remover o restante :-)
>>
>> Estou tentando acompanhar a thread mas não estou entendendo essa parte
>> da MBR, essa não é aquale pedacinho de 512 bytes no começo de cada
>> partição ou de cada disco? Também não captei como o gpart poderia
>> ajudar, seria fazendo um raid com as partições? Tipo, paliativo,
>
> MBR é de cada disco, e descreve quais partições (até 4) existentes no disco,
> e o setor de boot é no início de cada partição.
Camadas, camadas e camadas....
A BIOS vai procurar pelo MBR no primeiro setor do disco e depois vai executar o bootloader na partição ativa. Nesse ponto, o bootloader assume e executa o SO.
Mas eventualmente (para resolver o problema de só ser possível utilizar 4 partições), o bootloader (que pode fazer parte do SO ou não) pode implementar algumas 'mágicas' por conta própria.
Uma dessas mágicas são as partições extendidas que alguns SOs utilizam: windows, linux e mesmo no FreeBSD, que acabou levando o nome de BSD label (são os 16 'slices' que podemos criar dentro de cada uma das 4 partições definidas pelo MBR).
Para a BIOS, esses formatos extendidos não existem ela vê apenas suas 4 partições primárias e só mesmo o bootloader para saber identificar e trabalhar com a próxima 'camada'.
Aqui tem uma descrição do MBR (como são compostos os 'campos' do MBR nos seus 512 bytes):
http://en.wikipedia.org/wiki/Master_boot_record
E nesse link há mais algumas informações sobre os limites desse sistema:
http://en.wikipedia.org/wiki/Logical_block_addressing
> RAID com partições é só inventar bagunça, especialmente no caso que ele
> quer ter um disco inteiro de 4 GB. GPART é um esquema diferente para
> definir as partições, creio eu.
gpart(8) é uma (nova) ferramenta do FreeBSD para gerenciar partições:
http://www.freebsd.org/cgi/man.cgi?query=gpart&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html
Através dessa ferramenta é possível gerenciar vários formatos diferentes de particionamento através de uma interface única (necessário agora que o FreeBSD esta suportando mais e mais arquiteturas, como o port do PPC que vem evoluindo rapidamente).
Logo no inicio do manual há uma lista dos formatos suportados.
IMHO, depois do susto da mudança, o gpart(8) é muito mais simples de se trabalhar que o antigo fdisk(8).
Com o gpart(8) você pode criar um esquema GPT de partições (que vem substituindo a MBR em sistemas modernos).
O que muda ?
Utilizando GPT você terá:
- Suporte a 128 partições nativas (sem partições extendidas, xunxo, gambiarra ou o que seja);
- Backup da tabela de partição (o GPT mantém duas cópias da tabela de partição do disco, uma no primeiro setor e a outra no ultimo);
- Algumas outras pequenas melhorias, como 'label' nativo para as partições;
- Suporte a endereçamento de 64bits, que aumenta substancialmente o tamanho máximo dos discos suportados.
>
> Um disco de FreeBSD pode não ter partições, se pedir para usar o disco
> inteiro, como eu faço, mas o Ruindows, e alguns outros sistemas operacionais
> podem tentar ver o que tem no disco e não entender nada. Neste modo, o
> que seria a partição FreeBSD ocupa o disco inteiro, e não existe MBR.
>
>> xunxo?
>>
>> Essa barreira é vencida trocando o sistema para 64 bits? Essa troca eu
>> já estou considerando já que vou ter que trocar minha máquina urgente,
>> antes de 2035 :-)
Não existe relação nenhuma com o tipo do 'host' (maquinas de 32 ou 64bits), mesmo no amd64 o MBR é o mesmo - 512 bytes - (bem como suas limitações).
E da mesma forma, o formato GPT funciona em qualquer maquina/arquitetura 32bits.
>
> Tem um bug nos Unix que aparecerá em 2033, que é quando a data passa
> dos 2^31 segundos desde 01/01/1970 00:00. Se usar sem sinal o problema
> é adiado para 2107, quando chega a 2^32.
>
> Sou à favor de mudar a data para 64 bits, com resolução de micro-segundos,
> e permitindo datas desde antes de Cristo. Assim teríamos como representar
> desde 29227102 anos antes de Cristo até o ano 29227102. Acho que só alguma
> geração muito futura teria algum problema.
>
>
> João Rocha.
João, o time_t é feito para representar horários e datas 'humanas', datas de eventos que nós 'humanos' utilizamos para identifica-los.
Não acho que um 'timestamp' de uso uso generico deva ter 'microsegundos' (qual a data de nascimento dos seus filhos ? você lembra da hora ? do minuto ? do segundo ? e ainda do microsegundo ? heuehuhea)
Quando você precisa analisar eventos rápidos, há outras soluções, como os timers de alta resolução (HPET):
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
Assim você tem um pouco dos dois mundos, alta precisão e resolução (se preciso) e datas (timestamps) relativamente simples para todo o resto (resolução de 1 segundo).
Att.,
Luiz
Mais detalhes sobre a lista de discussão freebsd