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

Ao estender o tamanho, pois envolve a exclusão da partição, você terá que recriá-la novamente em qualquer número que ela 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 ao 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 moveria 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 as coisas.

PS. Quanto à minha opinião estritamente pessoal, o pequeno ganho de desempenho não faz valer a pena tirá-la do setor 63. Eu esperaria a máquina ser aposentada, 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, os setores reais certamente estarão alinhados com os setores virtuais e o VMWare fará com que seu hipervisor/VM extrairá um melhor desempenho do hardware.

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

Consultar os white papers de um especialista em armazenamento do setor para ter uma ideia melhor de quais são as melhores práticas atuais :

Sistemas operacionais (SO) suportados por fornecedores modernos de distribuidores Microsoft e Linux, como Red Hat, não exigem mais ajustes para alinhar a partição do sistema de arquivos com os blocos do sistema de armazenamento subjacente em um ambiente virtual.

(por exemplo, "deixe as configurações padrão em paz")

No entanto, para continuar respondendo à pergunta original, visite alguns white papers vinculados:

Alinhar suas partições a um limite de 4K no VMDK e no LUN é uma prática recomendada recomendada

E também:

Na saída de cada dispositivo, multiplique o início pelo tamanho do setor (normalmente 512 na saída do fdisk) e depois divida por 4096. Se o resultado for um número inteiro (número inteiro), está ALINHADO, caso contrário, está ALINHADO .

Então, verificando sua pergunta sobre como criar uma partição no setor 63:

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

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

512 * 2048 / 4096 = 156 => ALINHADO

Referências:

Perguntas frequentes: alinhamento de partição/disco do sistema de arquivos da VM convidada para VMware vSphere, outros ambientes virtuais e sistemas de armazenamento NetApp

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

Como alinhar blocos no VMWare ESX

Para referência:

• O setor 2048 em uma unidade de setor 512b convencional é o primeiro setor após a marca de 1 MB.
• O setor 63 é o setor logo 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 tornou razoavelmente padronizada).

Então, por que eles são relevantes?

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

• Deixa espaço para o bootloader. O formato MBR deixa apenas um pouco mais de 40 bytes para o bootloader. Isso pode ter sido suficiente nos dias de 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, realmente requer isso quando usado em um disco particionado MBR.
• Também é significativo ao lidar com discos particionados de várias maneiras. Alguns formatos de tabela 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 Apple com o SO clássico. Este é um uso muito mais de nicho, mas ainda é pelo menos um pouco relevante por causa do GPT.
• Alinhar suas partições para que elas comecem e terminem nos limites naturais da geometria do disco rígido (como limites de cilindro ou trilha) melhora o desempenho. O setor 63 está bem em um limite natural, e a maioria dos sistemas de arquivos não toca seu primeiro setor com muita frequência (se for o caso), então acaba colocando o segundo setor no início de um novo cilindro e geralmente também em o início de uma nova faixa, que geralmente é acessada com muita frequência em certos sistemas de arquivos mais antigos (embora não em alguns outros, ext4 e BTRFS, por exemplo, geralmente nunca a tocarão).

Por conta dos pontos 1 e 3, o setor 63 acabou se tornando o padrão. No entanto, em grande parte caiu em desuso por razões que descreverei abaixo.

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

Este é um pouco mais complicado. Não vi nenhuma resposta referenciada historicamente definitiva sobre o motivo pelo qual 1 MB foi escolhido, ou mesmo quando exatamente isso começou a ser a norma. A TI tem algumas vantagens:

• Acontece que está devidamente alinhado para os tamanhos de setor 512b e 4k, ao contrário de começar no setor 63, o que geralmente resultará no desalinhamento da maioria dos seus arquivos no próprio sistema de arquivos (este não era um problema originalmente com FAT12 e FAT16, pois eles geralmente padronizado para operar com setores 512b internamente).
• Muitos protocolos de armazenamento em rede definem 1 MB como o tamanho máximo de bloco para leituras e gravações. Alinhando partições assim, você acaba alinhado corretamente com esses protocolos de bloco, e assim evita a possibilidade de ter que fazer ciclos RMW quando você quer fazer apenas uma escrita parcial.
• A maioria dos SSDs modernos apresenta setores de 512b ou 4k, mas na verdade operam internamente com blocos muito maiores. Normalmente, esses são blocos de 2 MB ou 4 MB atualmente, mas muitos dos mais antigos usavam blocos de 1 MB. 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 exposto, mudar para 2048 como base deve realmente melhorar um pouco o desempenho da sua VM.

Também deve ser perfeitamente seguro, apenas certifique-se de reinstalar o bootloader após a movimentação, pois pode estar referenciando locais de bloco exatos no sistema de arquivos em vez de arquivos, que não apontarão para os locais corretos após a movimentação.

• Se você particionar seus discos com fdisk, o setor inicial será 2048+.
• Se você usar cfdisk, o que provavelmente acontece quando você adiciona um disco posteriormente, após a instalação inicial, o setor inicial pode ser 63.

Portanto, se você possui um disco com o setor inicial 63 e deseja redimensionar a partição, basta usar cfdiskem vez de fdisk.

Eu encontrei esse problema ao adicionar e redimensionar discos virtuais no ProxMox. Basicamente, se eu tivesse que mudar alguma coisa /dev/sda*eu usaria fdiske se eu precisasse redimensionar partições em /dev/sdb|c|detc, então eu estaria usando cfdisk. Aprendeu isso da maneira mais difícil.