RESUMO
Eu tenho um laptop Dell Inspiron 17-5767 com um disco interno de 1 TB. Permiti que o Windows 10 originalmente enviado continuasse a ter e dominar tudo sozinho (é meu sistema operacional para jogos). Além disso, tenho duas unidades externas a partir das quais inicializo e inicializarei meu sistema operacional Linux atual e futuro. Minha configuração atual é a seguinte:
- Porta USB 3.0 nº 0: Seagate Expansion+ 931,5 GiB (1000204885504 bytes) HDD externo reconhecido como /dev/sdb
- atualmente abrigando uma partição ext4 vazia e de tamanho normal, mas tem lutado para substituí-la por um esquema de particionamento alinhado ideal de 12 partições (o ponto de dificuldade é o alinhamento)
- Porta USB 3.0 nº 1: 238,5 GiB (256060514304 bytes) Samsung SSD 840 Pro reconhecido como /dev/sdc
- foi particionado usando o instalador do Fedora LiveCD (com a opção "custom") e hospeda minhas distros Linux Fedora LXDE e Lubuntu em um único LVM contendo um espaço de troca compartilhado, espaço de usuário compartilhado, raízes separadas e partições de inicialização externas separadas (por externo aqui, quero dizer apenas não no LVM, mas em suas próprias partições primárias separadas em outro lugar no mesmo disco)
- Esta unidade tem um tamanho de bloco físico e lógico de 512 e está perfeitamente alinhada, de acordo com o utilitário 'align-check opt x' do parted, e o fdisk também está satisfeito com o alinhamento (sem reclamações de alinhamento de qualquer utilitário)
- O UEFI BIOS tenta inicializar a partir do USB antes do interno, então recebo o grub aparecendo com todas as minhas opções disponíveis
META
Estou tentando replicar algo parecido com o que estou acontecendo com /dev/sdc na unidade /dev/sdb, mas com 5 distros Linux. Esse aspecto do meu projeto eu abordei, pois sou um multi-booter experiente. Mas a outra parte do meu objetivo é que meu particionamento em/dev/sdb esteja alinhado de maneira ideal, assim como é o caso de/dev/sdc, e é aqui que estou tendo problemas.
AMBIENTE
Atualmente estou trabalhando em minha instalação relativamente nova e atualizada do Fedora LXDE, e os resultados que estou obtendo são totalmente repetíveis em minha instalação também relativamente nova e atualizada do Lubuntu.
PARÂMETROS DE DISCO RELATADOS
[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C
Device Start End Sectors Size Type
/dev/sdb1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[root@frank ~]#
PROBLEMA
Portanto, com base no relatório do tamanho do bloco físico, parece que o disco tem 4k (formato avançado) em vez de 512b como a outra unidade, embora para fins de compatibilidade com versões anteriores ele esteja usando um tamanho de setor lógico de 512b. Posso dizer que o utilitário GNU parted está assumindo um tamanho de bloco de 512, porque quando calcula o intervalo IO ideal
(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval
ele obtém um valor de 65535, que é onde iniciará automaticamente a primeira partição, e a única maneira de o subutilitário de verificação de alinhamento passar um alinhamento de partição como ideal é se ele iniciar em um múltiplo de 65535. A única maneira de separar O resultado faz sentido se você considerar que está tratando o Physical_io_size como 512 em vez de 4096
(33553920 + 0) / 512 = 65535.
No entanto, parted compreensivelmente não pode usar o tamanho do bloco 4096, porque então a equação funcionaria para
(33553920 + 0) / 4096 = 8191.875.
Essa resposta satisfaria um professor de álgebra do ensino médio, mas obviamente não faz sentido como um intervalo setorial para o qual se esperaria um valor discreto (ou seja, um número inteiro!). De qualquer forma, como eu quero fazer 12 partições, algumas das quais têm tamanho tão pequeno quanto 256 MiB, isso não é possível fazer no GNU Parted usando porcentagens e, resumindo, só consegui satisfazer as verificações de alinhamento para um alinhamento ideal aderindo às 'unidades' e fazendo a aritmética modular sozinho para garantir que minhas partições começassem em intervalos de 65535s, do jeito que o parted queria que eu fizesse. Com base na minha pesquisa, não achei tão importante garantir que minhas partições também terminassem nesses intervalos e, portanto, fiquei com lacunas (obviamente não maiores que 65.535) entre a maioria das minhas partições.
Mais uma vez, o parted achou que meu resultado estava perfeitamente alinhado, tratando o tamanho do bloco físico como 512 em vez de 4096. Mas depois de sair do parted e executar 'fdisk -l /dev/sdb', obtive o seguinte conteúdo na saída:
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.
Então, o que o parted gosta, o fdisk não. Então tentei usar o gParted para refazer meu esquema de particionamento, deixando-o usar 1 MiB como tamanho da unidade, e ele iniciou a primeira partição em 2048, como você veria em meu outro disco (/dev/sdc). O fdisk ficou feliz e parou de reclamar do alinhamento do setor, mas então o GNU parted falhou nos testes de verificação de alinhamento para o modo ideal, embora passasse para o modo mínimo.
Descobri, no entanto, que em ambos os casos, mkswap (que usei para criar um volume de troca dentro do LVM que coloquei em /dev/sdb11) me deu o seguinte aviso:
[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned
Portanto, o mkswap descobre que meu volume de troca está desalinhado, independentemente de o parted achar que o disco está alinhado de maneira ideal ou mínima, e o mkswap também encontra meu volume de troca desalinhado, quer o fdisk esteja satisfeito com o alinhamento ou não.
TEORIAS
Tudo isso me deixa com a impressão de que posso ter que ignorar os avisos de pelo menos um utilitário de relatório ou particionamento de disco, mas não tenho certeza de qual deles. Também é possível que todos os relatórios não sejam confiáveis, pois o gabinete compatível com USB que contém o HDD pode estar reportando incorretamente pelo menos um dos parâmetros do setor. Por exemplo, talvez não seja realmente uma unidade AF? Ou talvez o tamanho ideal de IO esteja sendo relatado incorretamente. Ou talvez ambos? E, acredite, também considerei a possibilidade de que este seja um caso PEBKAC, pois posso estar entendendo mal algo sobre como alinhar partições em uma unidade de 4k. Eu não tenho certeza.
O que quer que esteja acontecendo, ficarei feliz em seguir em frente com minhas instalações reais do Linux, uma vez que acredito que minhas partições estão alinhadas de maneira ideal e mkswap, ou pelo menos os utilitários em que mais deveria confiar, parem de reclamar do alinhamento.
AJUDA
Por favor, ajude-me a entender por que não consigo fazer com que o parted e outros utilitários de disco concordem com algo além do alinhamento mínimo (alcançado apenas ao particionar com gParted ou gdisk) e, por favor, me informe se eu realmente deveria me preocupar demais. sobre as vantagens do alinhamento ideal sobre o alinhamento mínimo no meu caso, pois não perderei mais tempo se houver uma diferença muito insignificante no desempenho ou na integridade do disco. Caso contrário, gostaria de poder aproveitar ao máximo os benefícios de formato avançado do meu disco.
Responder1
Caso você ainda esteja confuso com o bizarro número 65535s. Também estou confuso com esta questão recentemente. Procurei uma resposta e me deparei com esta:http://gparted-forum.surf4.info/viewtopic.php?id=17839
Resumidamente, o ideal_io_size pode ser inválido quando o HD está conectado a um PC com um adaptador usb-sata.
A solução é simplesmente ignorar esse número e seguir a sugestão de limite de 1 MiB.