Início / unix / Perguntas / 783961
Accepted
Antti Keskinen
Asked: 2024-09-23 22:37:06 +0800 CST

De onde vem a informação "Tamanho físico"?

  • 772

Tenho um dispositivo Linux embarcado (não um Raspberry Pi) que tem duas partições em uma unidade eMMC. Usei uma ferramenta fornecida pelo fornecedor para copiar essas duas partições em uma unidade USB cujo tamanho é aproximadamente igual ao tamanho da unidade eMMC.

O que fiz em seguida foi montar a unidade USB em um computador Linux e usar ferramentas como e2fscke resize2fs -Mpara redimensionar o segundo sistema de arquivos para um tamanho mínimo viável e, finalmente, gdiskredimensionar a partição para corresponder.

Em todos os cálculos, tomei cuidado para garantir que a partição não ficasse menor que o sistema de arquivos, mesmo a ponto de tornar a partição um pouco maior e, então, resize2fsaumentar o sistema de arquivos para corresponder a ela.

Após essas operações, tenho uma unidade USB de 16 GB com uma partição de inicialização de 118 MiB e uma partição de sistema de arquivos raiz de 3,1 GiB. Em seguida, costumava ddler dados diretamente da unidade USB, utilizando parâmetros bs=e count=para limitar a quantidade de dados lidos para estender apenas até onde a segunda partição termina, mais um setor extra para acomodar o "setor zero".

O resultado é que agora tenho um arquivo de imagem no qual as duas partições têm exatamente o tamanho de suas fontes correspondentes, mas quando uso a opção "Arquivo" -> "Propriedades" da ferramenta 7-Zip, ele afirma que o "Tamanho físico" (circulado em vermelho) é maior que essas partições e maior do que o que instruí ddpara copiar da fonte.

De onde vem esse valor de "Tamanho físico"? Ele faz parte da tabela de partição? Ou lê dddo disco de alguma forma?

Existe alguma maneira de modificá-lo para me livrar do erro "Fim inesperado de dados"?

Imagem do 7-zip

filesystems

2 respostas

  1. Best Answer

    De onde vem esse valor "Tamanho físico"? Ele faz parte da tabela de partição?

    Sim.

    Veja a tabela de partição GUID - Wikipedia

    Existe alguma maneira de modificá-lo para me livrar do erro "Fim inesperado de dados"?

    Sim.

    Parece que as ferramentas padrão do Linux sabem como consertar um disco GPT truncado.

    Criando test-short.img com o mesmo problema

    $ dd if=/dev/zero bs=1M count=10 of=test.img
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0161485 s, 649 MB/s

$ gdisk test.img
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1): 
First sector (34-20446, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-20446, default = 20446) or {+-}size{KMGTP}: 18430    
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to test.img.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

$ dd if=test.img bs=1M count=9 of=test-short.img
9+0 records in
9+0 records out
9437184 bytes (9.4 MB, 9.0 MiB) copied, 0.00650826 s, 1.5 GB/s

    Como resolver o problema

    IIUC, você deixou um setor vazio no final do arquivo de imagem, que podemos usar para o "cabeçalho GPT secundário" (trailer?). Supondo que a tabela tenha as 128 entradas de partição usuais, você precisa adicionar outros 32 setores para elas, e então você pode consertar o problema.

    $ dd if=/dev/zero bs=512 count=32 >> test-short.img

$ gdisk test-short.img
GPT fdisk (gdisk) version 1.0.8

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk test-short.img: 18464 sectors, 9.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 01BD61C8-5DC3-42CA-824D-B5C1B3B09A77
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 20446
Partitions will be aligned on 2048-sector boundaries
Total free space is 4030 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           18430   8.0 MiB     8300  Linux filesystem

Command (? for help): x

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to test-short.img.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

    Para confirmar que test-short.img foi corrigido

    $ gdisk test-short.img
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk test-short.img: 18464 sectors, 9.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 01BD61C8-5DC3-42CA-824D-B5C1B3B09A77
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 18430
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           18430   8.0 MiB     8300  Linux filesystem

Command (? for help): q
    • 3

  2. Quando um sistema de arquivos é criado, 5% é reservado para gravações feitas pelo root. Isso foi originalmente planejado para permitir a recuperação pelo sistema mesmo após processos de usuário runway.

    Portanto, o "tamanho mínimo viável" não é viável para processos não raiz.

    Como alternativa, crie uma partição de 4 GB, faça sua cópia e reduza o tamanho para um mínimo adequado.

    • -1

relate perguntas