Parted não corretamente auto alinhando setores para usb drive

Question

Estou tentando particionar um drive usb 3, mas por algum motivo o parted não pode definir corretamente o setor inicial. A unidade é idêntica a várias outras unidades sata, a única diferença é que ela está dentro de um gabinete usb 3 com hub de 2 portas integrado. Eu não gostaria que isso importasse.

Aqui estão os passos que sempre usei antes:

sudo parted /dev/sd?
mklabel gpt
mkpart primary 0% 100%
quit

Aqui está a saída fdisk -l das últimas 2 unidades:

Disk /dev/sdk: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DB93D173-858A-475C-81CD-DB616E91C110

Device     Start         End     Sectors  Size Type
/dev/sdk1   2048 15628053134 15628051087  7.3T Linux filesystem


Disk /dev/sdl: 7.3 TiB, 8001563221504 bytes, 15628053167 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: B3791850-76F8-4CE2-B1CC-DF40886292CE

Device     Start         End     Sectors  Size Type
/dev/sdl1  65535 15628000379 15627934845  7.3T Linux filesystem

Partition 1 does not start on physical sector boundary.

O segundo disco é o problemático.

O desempenho realmente parece ter um grande sucesso, pois a formatação para o ext4 leva muito tempo (nunca esperou para terminar), onde normalmente levaria apenas alguns segundos. Por que isso está acontecendo? Como posso obter um alinhamento adequado?

A única diferença que posso pensar é que foi originalmente formatado como ntfs com algum espaço não particionado. Também executei este comando para limpar as partições restantes: dd if=/dev/zero of=/dev/sdl bs=512 count=10000 sem sorte.

O uso do alinhamento ideal não funciona:

sudo parted -a optimal /dev/sdl mkpart primary 0% 100%


Warning: You requested a partition from 0.00B to 8002GB (sectors 0..15628053166).
The closest location we can manage is 17.4kB to 1048kB (sectors 34..2047).
Is this still acceptable to you?

    

Answer 1

O tamanho ideal de E / S da segunda unidade é muito maior que o da primeira; isso é provavelmente o que está causando o problema. Este artigo de 2013 sugere para alinhar manualmente as partições iniciando em (Optimal I / O + Deslocamento de Alinhamento) / Tamanho do Bloco Físico = fatia inicial, e lendo como as palavras separadas hoje em dia parece que isso foi rolado para como o parted funciona por padrão. Agora, executar essa matemática em seus parâmetros retorna 8191.875 como a fatia inicial, o que provavelmente não é um endereço de setor válido.

Parece-me mais provável que o seu compartimento USB esteja representando erroneamente a E / S ideal da unidade. Eu tentaria especificar manualmente o setor inicial como 2048, correspondendo a primeira unidade, quando você faz a partição tentar usar mkpart primary 2048s 100% . Isso deve funcionar em torno disso.

Se você tiver a oportunidade, pode verificar isso antecipadamente, conectando a unidade a um computador sem o compartimento USB e, em seguida, verificando /sys/block/[drive]/queue/optimal_io_size se ele existir. Se não corresponder, o compartimento USB provavelmente está reportando incorretamente os recursos da unidade.

    

Answer 2

Este foi um problema em fdisk no util-linux. Eu relatei para o upstream há algum tempo e foi corrigido:

link

Portanto, se você usar o fdisk no util-linux v2.27-rc1 ou posterior para criar partições , você não enfrentará o problema.

Eu não tenho certeza se parted tem o mesmo problema, se isso acontecer, provavelmente ele deve introduzir um hack similar. (Então, envie um relatório de bug para o desenvolvedor se você deseja consertá-lo: link )

EDIT: Apenas observe que você está usando o GPT em ambos os discos. IIRC gdisk não sofre deste problema porque não calcula o alinhamento usando o tamanho de E / S ideal, em vez disso, ele é estaticamente padronizado como 2048 e permite configurá-lo para qualquer intervalo de valores de 1 a 65536 ( x - > l ).