É seguro forçar o fdisk a usar o limite do setor 63?

Question

Por alguma razão, a primeira partição do meu VPS (executando o Debian 8) está alinhada ao setor 63 (em vez de 2048)

Model: VMware Virtual disk (scsi)
Disk /dev/sda: 314572800s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start      End         Size        Type     File system     Flags
 1      63s        79971569s   79971507s   primary  ext4            boot
 2      79971570s  83875364s   3903795s    primary  linux-swap(v1)
        83875365s  314572799s  230697435s           Free Space

Agora quero redimensionar as partições para alocar o espaço livre, infelizmente fdisk inicia o primeiro setor em 2048. Mas como eu li aqui , é possível forçar fdisk a comece em 63 usando este comando.

fdisk -c=dos -u=cylinders /dev/sda

Quão seguro é isso? Além disso, como este método é obsoleto, isso prejudica o desempenho do meu VPS?

    

Answer 1

Ao estender o tamanho, uma vez que envolve a exclusão da partição, você terá que recriá-lo novamente em qualquer número que iniciar.

caso contrário, não será reconhecido na melhor das hipóteses e, na pior das hipóteses, pode haver corrupção de dados.

Se esse VPS for um modelo para criar outras VMs, eu me daria o trabalho de recriar / mover o início * e * os dados / setores para o setor 2048.

Como é uma VM, se você quiser mover a partição, eu não a moverei exatamente, criaria uma partição ao lado, copiaria os dados e inicializaria com a partição de cópia. Essa é a beleza de trabalhar com máquinas virtuais, você tem mais espaço para testar coisas.

PS. Quanto à minha opinião estritamente pessoal, o pequeno ganho no desempenho não vale a pena transferi-lo do setor 63. Eu esperaria a máquina se aposentar, isso acontecerá mais cedo ou mais tarde.

Quanto ao alinhamento de partições:

Você deseja deixar a partição alinhada ao limite de 4096 bytes. Dessa forma, setores reais são, na maioria das vezes, alinhados com setores virtuais e o VMWare fará com que seu hipervisor / VM extraia um melhor desempenho do hardware.

Para entender por que as partições desalinhadas são um problema de desempenho, veja esta imagem em purestorage.com:

Consultaroswhitepapersdeumespecialistaemarmazenamentonaindústriaparaterumaideiamelhordasmelhorespráticasatuais:

Modernvendor-supportedoperatingsystems(OS)fromMicrosoftandLinuxdistributorssuchasRedHatnolongerrequireadjustmentstoalignthefilesystempartitionwiththeblocksoftheunderlyingstoragesysteminavirtualenvironment.

(porexemplo,"deixe as configurações padrão sozinho")

No entanto, para continuar respondendo à pergunta original, visite alguns documentos oficiais vinculados:

Aligning your partitions to a 4K boundary in both the VMDK and the LUN is a recommended best practice

E também:

In the output for each device, multiply the start by sector size (normally 512 in the fdisk output), and then divide it by 4096. If the result is an integer (whole number), it is ALIGNED, if not, it is MISALIGNED.

Portanto, verifique sua pergunta sobre como criar uma partição no setor 63:

512 * 63/4096 = 7,875 = > MALIZADO

Eu provavelmente usaria e deixaria o padrão no futuro em 2048. Vamos verificar:

512 * 2048/4096 = 156 = > ALINHADO

Referências:

FAQ: partição do sistema de arquivos guest VM e alinhamento de disco para o VMware vSphere, outros ambientes virtuais e armazenamento NetApp sistemas

Como corrigir o alinhamento da partição de dados da VM guest em um ambiente do VMware vSphere 5.x

Como alinhar blocos no VMWare ESX

    

Answer 2

Para referência:

• O setor 2048 em uma unidade de setor 512b convencional é o primeiro setor após a marca de 1MB.
• O setor 63 é o setor direito antes da marca de 32k, e originalmente correspondia ao último setor da primeira faixa no primeiro prato da maioria dos discos rígidos (pelo menos, uma vez que a geometria do disco se tornasse razoavelmente padronizada ).

Então, por que isso é relevante?

Existem algumas razões pelas quais você não inicia convencionalmente partições no setor 1:

• Isso deixa espaço para o gerenciador de inicialização. O formato MBR deixa apenas pouco mais de 40 bytes para o bootloader. Isso pode ter sido suficiente nos dias CP / M e DOS, mas rapidamente se tornou muito pequeno. Então, a convenção tornou-se que você deixou a primeira faixa (quase inteira) do primeiro prato para o bootloader. O GRUB, por exemplo, requer isso quando usado em um disco particionado do MBR.
• Também é significativo ao lidar com discos particionados de várias maneiras. Alguns formatos de tabelas de partição não iniciam no setor 0. Um exemplo moderno disso é o GPT, que começa no setor 1 e convencionalmente vai até o setor 31. Um exemplo muito mais antigo é o formato de tabela de partição usado pelos sistemas da Apple. com o sistema operacional clássico. Este é um nicho muito mais usado, mas ainda é pelo menos um pouco relevante por causa da GPT.
• Alinhar suas partições para que elas comecem e terminem em limites naturais da geometria do disco rígido (como limites de cilindro ou de trilha) melhora o desempenho. O setor 63 está exatamente na fronteira natural, e a maioria dos sistemas de arquivos não toca o seu primeiro setor com muita frequência (se é que o faz), então acaba colocando o segundo setor no início de um novo cilindro, e geralmente também no primeiro setor. o início de uma nova faixa, que geralmente é acessada com muita freqüência em certos sistemas de arquivos antigos (embora não em todos os outros, o ext4 e o BTRFS, por exemplo, geralmente nunca o tocam).

Por causa dos pontos 1 e 3, o setor 63 acabou se tornando o padrão. No entanto, está em grande parte fora de uso por razões que descreverei abaixo.

OK, então por que aumentou para 1MB?

Este é um pouco mais complicado. Eu não vi nenhuma resposta real e definitiva referenciada historicamente porque por que 1MB foi escolhido, ou mesmo quando exatamente isso começou a ser a norma. A TI tem algumas vantagens:

• Acontece que ele está alinhado adequadamente para os tamanhos dos setores 512b e 4k, diferente de iniciar no setor 63, o que normalmente resultará na maioria de seus arquivos no sistema de arquivos sendo desalinhado (isso não foi um problema originalmente com o FAT12 e o FAT16, já que eles geralmente optavam por operar com 512b setores internamente).
• Muitos protocolos de armazenamento em rede definem 1 MB como o tamanho máximo de bloco para leituras e gravações. Ao alinhar partições como essa, você acaba alinhando-se adequadamente com esses protocolos de bloco e, assim, evita a possibilidade de ter que fazer ciclos de RMW quando desejar fazer apenas uma gravação parcial.
• A maioria dos SSDs modernos apresenta setores 512b ou 4k, mas eles operam internamente com blocos muito maiores. Normalmente, esses são blocos de 2MB ou 4MB atualmente, mas muitos dos mais antigos usaram blocos de 1MB. O alinhamento adequado com esses blocos melhora significativamente a expectativa de vida de alguns SSDs e também melhora significativamente o desempenho de gravação.

OK, mas e a pergunta original?

Dado o acima, mover para 2048 como base deve melhorar o desempenho um pouco para sua VM.

Também deve ser perfeitamente seguro, apenas certifique-se de reinstalar o gerenciador de inicialização após a movimentação, pois ele pode estar referenciando locais de blocos exatos dentro do sistema de arquivos em vez de arquivos, que não apontarão para os locais corretos após a movimentação. / p>