Offset de partição em 63 ou 64?

2

Eu não queria usar todo o SSD para o OpenBSD 5.5. (O SSD é novo e pré-formatado com o MSDOS usando o Gparted)

Durante a instalação e no estágio fdisk, escolhi a Partição #: 0 para instalar o OpenBSD (alterei o ID da Partição para a6). Eu pretendo instalar outro sistema operacional similar ao Unix na Partição #: 1 ou 2.

Quando solicitado pelo deslocamento da partição (o padrão é 0), eu digitei 64 em vez de 63 (eu li em algum lugar na internet que para SSDs, o deslocamento deve começar em 64). Isso está correto?

Abaixo estão detalhes adicionais sobre a geometria do disco do meu SSD:

A instalação prosseguiu sem problemas sem problemas.

Após a reinicialização da minha máquina, as últimas linhas foram as mensagens de erro:

root on sd0a swap on sd0b dump on sd0b
panic: root filesystem has size 0
Stopped at Debugger+0x5 : leave
Run at least 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}>
    
por user66229 05.08.2014 / 22:06

2 respostas

2

O deslocamento é especificado em setores de 512 bytes. Seu deslocamento alternativo de 63 vem da geometria C / H / S, que é obsoleta e deve ser ignorada.

Offset 64 soa melhor que 63. É claramente mais uniforme - fornece alinhamento para 512 * 64 = 32KiB. Você definitivamente quer mirar no alinhamento do 4KiB. (Mesmo se você não estivesse usando um SSD - os discos rígidos agora são baseados em setores 4KiB internamente).

Pessoalmente, eu tentaria alinhar a 1 MiB. Isso seria (1024 * 1024) / 512 = 2048 setores.

Todos os outros sistemas operacionais atuais são projetados para alinhar a 1 MiB. (Isto é, bloqueando insetos). Furar a isso pode evitar bugs estranhos. Também pode tornar a tabela de partições mais fácil de entender, quando você instala outros sistemas operacionais (particularmente Linux ou Windows), se eles usam o mesmo alinhamento que o seu BSD. Se for mais fácil entender, será mais fácil detectar bugs. Estou pensando aqui em um desalinhamento ao criar partições em um disco existente, que encontrei em uma versão anterior do Debian.

Os modernos flash eraseblocks são muito maiores que 32KiB: 128KiB / 256KiB, pelo menos. Dito isto, acho que é importante para fins de RAID. Porque isso só importa para grandes IOs, e seu sistema de arquivos não está necessariamente alinhado internamente a 1 MiB de qualquer maneira.

Quando você disse que o deslocamento padrão é 0, isso me preocupou. O setor 0 não pode ser usado para uma partição, porque é ocupado pela tabela de partições MBR (MBR de proteção se você estiver usando o GPT). Se 0 era um desvio válido, sugeriria que você (BSD) estivesse contando de algum outro lugar, por exemplo, logo após o MBR, e precisaríamos compensar isso.

Sua atualização responde à minha preocupação. A especificação do deslocamento inválido 0 é considerada como "este número de partição não é usado".

(Ele também explica porque você descreveu "escolher" qual (is) partição (s) usar para seus propósitos. Eu teria descrito "criando" eles, porque é assim que o fdisk do Linux mostra. você tem uma visão mais literal do formato da tabela de partição subjacente).

    
por 06.08.2014 / 10:33
-1

Sim, se você tiver problemas como esse, uma boa maneira de resolvê-lo é cat / dev / zero > / dev / disk (todo um) para que zere tudo e comece de novo com o disco devidamente alinhado. Às vezes, ele gera erros quando encontra partes do código de inicialização que estavam lá antes.

    
por 11.10.2014 / 21:56