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 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 é ligeiramente maior que a partição de entrada. Ambas são ext3partições.
Executando a partir do CD OpenSuse-Rescue LIVE. Yast mostra que a partição de entrada ( sdb1) é de 62,5 GiB e a de saída sdb2é de 62,85 GiB.
Thunar mostra que a entrada sdb1é de 65,9 GB e a de saída sdb2é de 66,2 GB, enquanto o ddarquivo de imagem de saída também está sendo de 66,2, então obviamente está no máximo sdb2.
Aqui está o console:
( sdb1foi desmontado, tentei ddalgumas 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 mediante solicitação:
E novamente: estou vendo a diferença no tamanho da partição de origem sdb1e no arquivo de imagem DD RR.imagecriado a partir dela. Esse arquivo reside em sdb2.
Ainda há algo que não está claro aqui: estou RUNNING DD AS ROOT, para que o espaço reservado esteja disponível para gravação, correto? A meta sdb2é 62,85 GiB, enquanto o total de bytes da imagem, como você disse, é de cerca de 61,63 GiB. Aqui também está a saída dfe POSIXLY_CORRECT=1 dfos comandos:
O sistema agora é 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 iguais aos do simples dfse dividirmos por 2. 1024b/512b=2 é o divisor.
sdb1É menor quesdb2. O uso de 100 por centosdb2agora é devido ao arquivo de imagem DD que preencheu a partição. Deve ser o único arquivo nele agora.O arquivo de imagem em si tem 66.176.851.968 bytes no DD (em tempo de execução) e nos relatórios Thunar. Dividido por 1.024 bytes, obtemos 64625832 blocos K, correto? Portanto, ainda é menor do que
dfo relatadosdb2em mais de 116380K e é MAIOR QUE Asdb1(A FONTE), mas maximiza a partiçãosdb2.
A questão é: o que há aí para ocupar esse espaço sdb2?
Mas o mais importante e interessante é:
Por que o arquivo de destino é maior que a partição de origem que ddo criou? O que significa para mim: não posso responder.
sdb1(64376668K) < RR.image(64625832K)
E
sdb1(64376668 blocos de 1K) < RR.image(64625832 blocos de 1K) < sdb2(64742212 blocos de 1K)
(Espero que as coisas tenham sido calculadas corretamente…)
Agora verifiquei os blocos que estão reservados para ROOT. 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, caso isso seja importante.
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 disso sdb1?
sdb2(N2) não é 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 on sdb2, ele caberá lá?
Responder1
Todo sistema de arquivos precisa de algum espaço para metadados. Além disso extfamíliareserva algum espaço para rooto usuárioe é 5% por padrão.
Exemplo
No meu Kubuntu criei um arquivo (esparso) de 1GiB:
truncate -s 1G myfile
e criou ext3um sistema de arquivos dentro dele. O comando era claro
mkfs.ext3 myfile
Isso alocou instantaneamente cerca de 49 MiB (~ 5% neste caso) para o arquivo myfile. Pude ver isso porque o arquivo era esparso e inicialmente relatava uso de 0B em meu disco real, depois cresceu. Presumo que é aqui que residem os metadados.
Montei o sistema de arquivos; df -hrelatou 976 MiB de espaço total, mas apenas 925 MiB disponíveis. Isso significa que outros cerca de 5% não estavam disponíveis para mim.
Então preenchi este espaço (depois cddo ponto de montagem) com
dd if=/dev/urandom of=placeholder
Como usuário regular, consegui apenas 925 MiB. O uso de "disco" relatado foi então de 100%. No entanto, fazendo o mesmo que um root, eu poderia escrever 976 MiB no arquivo. Quando o arquivo ultrapassou 925 MiB, o uso permaneceu em 100%.
Conclusão
Comparar tamanhos de suas partições é errado neste caso; o mesmo acontece com a comparação dos tamanhos dos seus sistemas de arquivos. Você deveria ter verificado o espaço disponível no alvosistema de arquivo(por exemplo, com df) e compare-o com o tamanho da fontepartição.
EDITAR:
Para deixar claro: seus 66176851968 bytes têm cerca de 61,63 GiB. Isso énãomaior que a partição de origem que é 62,5 GiB. A fontepartiçãonão foi totalmente lido quando o alvosistema de arquivoficou cheio.
Caso você não esteja familiarizado com a distinção GB/GiB, leiaman 7 units.
EDITAR 2
Agora temos todos os números reais. Vamos nos ater à unidade 512B, é um tamanho de setor comum.
- Seu
sdb1partiçãoocupa131074048-2048=131072000unidades no disco. Vamos chamar issoP1. Isto é dagdisksaída. - Seu
sdb2partiçãoocupa262889472-131074048=131815424unidades no disco. Deixe estarP2. Isso também vem dagdisksaída. - Seusistema de arquivodentro
sdb1pode armazenar arquivos até128753336um total de unidades. Vamos ligar para esse númeroF1. Isto é dadfsaída. - Seusistema de arquivodentro
sdb2pode armazenar até129484424unidades. Deixe estarF2. Isso também vem dadfsaída.
A diferença entre P1e F1, assim como a diferença entre P2e F2, pode ser explicada se você souber que deve haver espaço para metadados. Isso é mencionado anteriormente nesta resposta.
Você ddtentou copiar o todosdb1 partição, ou seja, P1de dados, em um arquivo que ocupa o espaço fornecido pelosistema de arquivodentro sdb2, ou seja, F2de espaço disponível.
P1> F2– esta é a resposta final.Seu arquivo de imagem não ficou maior do que deveria. Parece-me que você esperava que seu tamanho fosse F1. Na verdade, toda a imagem teria um tamanho de P1unidades.
P2e F1são irrelevantes neste contexto.
Responder2
Depois dessa longa discussão, percebi o que você quis dizer.
Finalmente chegamos ao ponto. Bem, minha pergunta estava meio obscura inicialmente, antes de editá-la. Realmente obrigado!
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ção: msdos
Sinalizadores de disco:
Número Início Fim Tamanho Tipo Sistema de arquivos Sinalizadores
1 1048576B 67109912575B 67108864000B inicialização ext3 primária
2 67109912576B 134599409663B 67489497088B primário ext3
4 134600457216B 154668105727B 20067648512B estendido
5 134600458240B 150410887167B 15810428928B ext4 lógico
6 150411935744B 154668105727B 4256169984B troca lógica de Linux (v1)
3 154668105728B 160041009151B 5372903424B gordura primária32 lba
Então, basicamente, preciso comparar o tamanho real do sdb1 (N1) nesta lista com o espaço disponível no sdb2 (N2) nesta lista.
Mas para isso usamos o comando POSIXLY_CORRECT=1 df no sistema de arquivos de destino (sdb2) que era: 129484424 512b-blocks 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). É claro que a imagem da partição sdb1 não cabe no espaço disponível no sdb2. E existe um espaço reservado para ROOT no sdb2 que também deve ser levado em consideração.
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 por completo pelo DD. Correto? Posso até aproximar quanto espaço preciso para a operação ser concluída: 66.176.851.968 bytes era o tamanho da imagem DD incompleta, então comparo-o com o tamanho da partição sdb1 bruta 66.176.851.968 = 66176851968 B <67108864000 B = menor em 932012032 Bytes = 888 MiB
Mas ei, o que há na partição vazia? Metadados e espaço reservado para root? Tanto espaço ???!!!!! Muito obrigado!!
Que bom saber de tudo isso!!