Por que o arquivo de imagem de saída do DD é maior que a partição de origem / fica sem espaço ao copiar a partição para um arquivo

Question

O arquivo de imagem de saída do DD é maior que a partição de origem e o DD fica sem espaço na partição de destino (onde a imagem é criada), apesar de ser maior do que a partição de origem.

Estou tentando copiar uma partição para um arquivo em outra partição no mesmo disco. A partição de destino é um pouco maior que a partição de entrada. Ambos são ext3 partitions.

Executando a partir do CD do OpenSuse-Rescue LIVE. Yast mostra a partição de entrada ( sdb1 ) é 62,5 GiB e a saída uma sdb2 é 62,85 GiB.

Thunar mostra a entrada sdb1 é 65,9 GB e a saída 1 sdb2 é 66,2 GB, enquanto a saída dd arquivo de imagem também está sendo 66,2 então obviamente excedendo sdb2 .

Aqui está o console:

( sdb1 foi desmontado, tentou dd algumas vezes)

linux:# dd if=/dev/sdb1 of=RR.image bs=4096

dd: error writing ‘RR.image’: No space left on device
16156459+0 records in
16156458+0 records out
66176851968 bytes (66 GB) copied, 2648.89 s, 25.0 MB/s

Informações adicionais por solicitação:

E novamente: estou vendo a diferença no tamanho da partição de origem sdb1 e o arquivo de imagem DD RR.image criado a partir dele. Esse arquivo reside em sdb2 .

Ainda há algo pouco claro aqui: eu estou executando DD como RAIZ, de modo que o espaço reservado está disponível para escrever, correto? O destino sdb2 é 62.85 GiB, enquanto o total de bytes para a imagem, como você disse, é de cerca de 61.63 GiB. Aqui está também a saída dos comandos df e POSIXLY_CORRECT=1 df :

O sistema agora é o system-rescue-cd

root@sysresccd /root % df

Filesystem 1K-blocks Used Available Use% Mounted on
…
/dev/sdb1 64376668 7086884 56241208 12% /media/Data1
/dev/sdb2 64742212 64742212 0 100% /media/Data2
/dev/sdb3 5236728 4785720 451008 92% /usr/local

root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb1 
Filesystem     512B-blocks     Used Available Use% Mounted on
/dev/sdb1        128753336 14173768 112482416  12% /media/Data1

root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb2    
Filesystem     512B-blocks      Used Available Use% Mounted on
/dev/sdb2        129484424 129484424         0 100% /media/Data2

Os números são exatamente os mesmos que no simples df se dividirmos por 2. 1024b / 512b = 2 é o divisor.

1. sdb1 é menor que sdb2 . O uso de 100% em sdb2 agora é devido ao arquivo de imagem DD que preencheu a partição. Tem que ser o único arquivo agora.

2. O arquivo de imagem em si é 66,176,851,968 bytes do DD (em tempo de execução) e os relatórios do Thunar. Dividido por 1024 bytes obtemos 64625832 K-blocks correto? Portanto, ele ainda é menor que df informado para sdb2 em mais de 116380K e é MAIOR QUE O sdb1 (THE SOURCE), mas maximiza a partição sdb2 .

A questão é: o que está lá para ocupar esse espaço em sdb2 ?

Mas o mais importante e interessante é:

Por que o arquivo de destino é maior que a partição de origem da qual o dd o criou? O que significa para mim: não posso escrever de volta.

sdb1 (64376668K) < RR.image (64625832K)

e

sdb1 (64376668 blocos de 1 K) < RR.image (64625832 blocos de 1 K) < sdb2 (64742212 blocos de 1 K)

(espero que as coisas tenham sido calculadas corretamente ...)

Agora eu verifiquei os blocos que são recuperados para ROOT. Eu encontrei este comando para executar:

root@sysresccd /root % dumpe2fs -h /dev/sdb1 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'

Reserved blocks: 1.6%

root@sysresccd /root % dumpe2fs -h /dev/sdb2 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'

Reserved blocks: 1.59999%

Portanto, a porcentagem reservada para ROOT também é a mesma em ambas as partições, no caso que importa.

Aqui está a saída para gdisk :

root@sysresccd /root % gdisk -l /dev/sdb

GPT fdisk (gdisk) version 1.0.1

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


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************

Disk /dev/sdb: 312581808 sectors, 149.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DCF8AFC4-11CA-46C5-AB7A-4818336EBCA3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 2048-sector boundaries
Total free space is 7789 sectors (3.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       131074047   62.5 GiB    8300  Linux filesystem
   2       131074048       262889471   62.9 GiB    8300  Linux filesystem
   3       302086144       312580095   5.0 GiB     0700  Microsoft basic data
   5       262891520       293771263   14.7 GiB    8300  Linux filesystem
   6       293773312       302086143   4.0 GiB     8200  Linux swap

Então qual é o tamanho real de sdb1 então?

Não é sdb2 (N2) maior que sdb1 (N1)? Então, por que o arquivo de imagem CRESCE MAIOR que sdb2 (N2)? Se eu desligar o espaço reservado para root em sdb2 , ele deve caber aí?

    

Answer 1

Todo sistema de arquivos precisa de algum espaço para metadados. Além disso, ext family reserva algum espaço para root user e é 5% por padrão.

Exemplo

No meu Kubuntu eu criei um arquivo (esparso) de 1GiB:

truncate -s 1G myfile

e fez ext3 filesystem dentro dele. O comando estava claro

mkfs.ext3 myfile

Isso alocou instantaneamente cerca de 49 MiB (~ 5% neste caso) para o myfile . Eu pude ver isso porque o arquivo era escasso e inicialmente relatava o uso de 0B no meu disco real, então ele cresceu. Eu suponho que é onde os metadados vivem.

montei o sistema de arquivos; df -h relatou 976 MiB de espaço total, mas apenas 925 MiB disponível. Isso significa que outros ~ 5% não estavam disponíveis para mim.

Depois preenchi este espaço (depois de cd para o ponto de montagem) com

dd if=/dev/urandom of=placeholder

Como usuário comum, consegui apenas 925 MiB. O uso de "disco" relatado foi de 100%. No entanto, fazendo o mesmo que um root , eu poderia escrever 976 MiB no arquivo. Quando o arquivo cresceu mais de 925MiB, o uso permaneceu em 100%.

Conclusão

Comparar os tamanhos das suas partições está errado neste caso; Então, está comparando os tamanhos dos seus sistemas de arquivos. Você deve ter verificado o espaço disponível no sistema de arquivos de destino (por exemplo, com df ) e compará-lo com o tamanho da partição de origem .

EDITAR:

Para deixar claro: seus 66176851968 bytes são cerca de 61.63 GiB. Isso não é maior que a partição de origem que é 62,5 GiB. A partição fonte não foi totalmente lida quando o sistema de arquivos alvo ficou cheio.

Caso você não esteja familiarizado com a distinção GB / GiB, leia man 7 units .

EDIT 2

Agora temos todos os números reais. Vamos nos ater à unidade de 512B , é um tamanho de setor comum.

• Sua sdb1 partição ocupa 131074048-2048=131072000 unidades no disco. Vamos chamar isso de P1 . Isso é de gdisk output.
• Sua sdb2 partição ocupa 262889472-131074048=131815424 unidades no disco. Deixe ser P2 . Isso também é de gdisk output.
• Seu sistema de arquivos dentro de sdb1 pode armazenar arquivos até 128753336 units total. Vamos chamar esse número F1 . Isso é de df output.
• Seu sistema de arquivos dentro de sdb2 pode armazenar até 129484424 unidades. Deixe ser F2 . Isso também é de df output.

A diferença entre P1 e F1 , assim como a diferença entre P2 e F2 , pode ser explicada se você souber que deve haver espaço para metadados. Isso é mencionado anteriormente nesta resposta.

Seu dd tentou copiar a partição sdb1 , ou seja, P1 dos dados, em um arquivo que ocupa o espaço fornecido pelo sistema de arquivos dentro de sdb2 , ou seja, F2 do espaço disponível.

P1 > F2 - esta é a resposta final. Seu arquivo de imagem não cresceu mais do que deveria. Parece que você esperava que seu tamanho fosse F1 . Na verdade, toda a imagem teria um tamanho de P1 unidades.

P2 e F1 são irrelevantes neste contexto.

    

Answer 2

Depois dessa longa discussão, percebi o que você quis dizer.

Chegamos ao ponto finalmente. Bem, minha pergunta foi meio obscura antes de editá-la. Muito obrigado!

Eu encontrei este comando para obter o tamanho exato das partições em bytes:

root @ sysresccd / root% parted / dev / sdb unidade B p

Modelo: ATA WDC WD1600AAJS-0 (scsi)

Disco / dev / sdb: 160041885696B

Tamanho do setor (lógico / físico): 512B / 512B

Tabela de Partições: msdos

Sinalizadores de disco:

Number Start End Tamanho Tipo Sinalizadores do sistema de arquivos

1 1048576B 67109912575B 67108864000B boot ext3 principal

2 67109912576B 134599409663B 67489497088B ext3 principal

4 134600457216B 154668105727B 20067648512B estendido

5 134600458240B 150410887167B 15810428928B ext4 lógico

6 150411935744B 154668105727B 4256169984B linux-swap lógico (v1)

3 154668105728B 160041009151B 5372903424B principal fat32 lba

Então, basicamente, preciso comparar o tamanho real de sdb1 (N1) nesta lista com o espaço disponível em sdb2 (N2) nesta lista.

Mas para isso usamos o comando POSIXLY_CORRECT = 1 df no sistema de arquivos de destino (sdb2) que era: 129484424 blocos 512b neste caso.

Se dividirmos 67108864000B de sdb1 por 512 b = 131072000 512b-blocks.  Ou podemos multiplicar 129484424 * 512 = 66296025088 Bytes.

Portanto, 66296025088 bytes (espaço disponível em sdb2) < 67108864000 bytes (tamanho bruto de sdb1).  Claramente que a imagem da partição sdb1 não pode caber no espaço disponível em sdb2.   E há um espaço reservado para ROOT em sdb2 que também deve ser levado em conta.

E a partir da minha pergunta sobre o arquivo de imagem maior que a partição, comparei basicamente o tamanho do sistema de arquivos sdb1 com a imagem DD, em vez do tamanho bruto da partição, que deve ser lido integralmente pelo DD.   Corrigir? Posso até mesmo aproximar quanto espaço eu preciso para a operação ser concluída:  66.176.851.968 bytes foi o tamanho da imagem DD incompleta, então eu comparo com o tamanho da partição sdb1 bruta 66,176,851,968 = 66176851968 B < 67108864000 B = menor por 932012032 Bytes = 888 MiB

Mas ei o que está lá na partição vazia? Metadados e espaço reservado para raiz? Tanto espaço ??? !!!!! Muito obrigado !!

É bom saber tudo isso !!