El archivo de imagen de salida de DD es más grande que la partición de origen y DD se queda sin espacio en la partición de destino (donde se crea la imagen) a pesar de ser más grande que la partición de origen.
Estoy intentando copiar una partición a un archivo en otra partición en el mismo disco. La partición de destino es ligeramente más grande que la partición de entrada. Ambas son ext3particiones.
Ejecutando desde OpenSuse-Rescue LIVE CD. Yast muestra que la partición de entrada ( sdb1) es de 62,5 GiB y la de salida sdb2es de 62,85 GiB.
Thunar muestra que la entrada sdb1es de 65,9 GB y la de salida sdb2es de 66,2 GB, mientras que el ddarchivo de imagen de salida también tiene 66,2, por lo que obviamente está al máximo sdb2.
Aquí está la consola:
( sdb1fue desmontado, probado ddvarias veces)
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
Información adicional previa solicitud:
Y nuevamente: veo la diferencia en el tamaño de la partición de origen sdb1y el archivo de imagen DD RR.imageque creó a partir de ella. Ese archivo reside en sdb2.
Todavía hay algo que no está claro aquí: estoy EJECUTANDO DD COMO RAÍZ, por lo que hay espacio reservado disponible para escribir, ¿correcto? El objetivo sdb2es 62,85 GiB, mientras que el total de bytes de la imagen, como dijiste, es de aproximadamente 61,63 GiB. Aquí también está el resultado de los comandos dfy POSIXLY_CORRECT=1 df:
El sistema ahora es 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
Los números son exactamente iguales que en simple dfsi lo dividimos entre 2. 1024b/512b=2 es el divisor.
sdb1es más pequeña quesdb2. El uso del 100 por cientosdb2ahora se debe al archivo de imagen DD que llenó la partición. Tiene que ser el único archivo que contiene ahora.El archivo de imagen en sí tiene 66.176.851.968 bytes en el momento de DD (en tiempo de ejecución) e informa Thunar. Dividido por 1024 bytes obtenemos 64625832 bloques K, ¿correcto? Por lo tanto, todavía es más pequeño de
dflo informadosdb2en más de 116380K y es MÁS GRANDE QUEsdb1(LA FUENTE), pero maximiza la particiónsdb2.
La pregunta es: ¿qué hay ahí para ocupar ese espacio sdb2?
Pero lo más importante e interesante es:
¿Por qué el archivo de destino es más grande que la partición de origen dddesde la que se creó? Lo que significa para mí: no puedo volver a escribirlo.
sdb1(64376668K) < RR.image(64625832K)
Y
sdb1(64376668 bloques de 1K) < RR.image(64625832 bloques de 1K) < sdb2(64742212 bloques de 1K)
(Espero que las cosas hayan sido calculadas correctamente…)
Ahora verifiqué los bloques que están reservados para ROOT. Encontré este comando para ejecutar:
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%
Entonces, el porcentaje reservado para ROOT también es el mismo en ambas particiones en caso de que eso importe.
Aquí está el resultado de 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
Entonces, ¿cuál es el tamaño real de sdb1entonces?
¿No es sdb2(N2) mayor que sdb1(N1)? Entonces, ¿POR QUÉ el archivo de imagen CRECE MÁS GRANDE que sdb2(N2)? Si desactivo el espacio reservado para root en sdb2, ¿cabrá allí entonces?
Respuesta1
Cada sistema de archivos necesita algo de espacio para los metadatos. adicionalmente extfamiliareserva algo de espacio para rootel usuarioy es del 5% por defecto.
Ejemplo
En mi Kubuntu creé un archivo (escaso) de 1GiB:
truncate -s 1G myfile
y creó ext3un sistema de archivos dentro de él. La orden era clara
mkfs.ext3 myfile
Esto asignó instantáneamente alrededor de 49MiB (~5% en este caso) al archivo myfile. Pude ver eso porque el archivo era escaso e inicialmente reportaba un uso de 0B en mi disco real, luego creció. Supongo que aquí es donde viven los metadatos.
Monté el sistema de archivos; df -hinformó 976MiB de espacio total, pero solo 925MiB disponibles. Esto significa que otro ~5% no estaba disponible para mí.
Luego llené este espacio (después cddel punto de montaje) con
dd if=/dev/urandom of=placeholder
Como usuario habitual, solo pude tomar 925MiB. El uso del "disco" informado fue entonces del 100%. Sin embargo, haciendo lo mismo que a root, podría escribir 976MiB en el archivo. Cuando el archivo superó los 925MiB, el uso se mantuvo en el 100%.
Conclusión
Comparar los tamaños de sus particiones es incorrecto en este caso; también lo es comparar los tamaños de sus sistemas de archivos. Deberías haber comprobado el espacio disponible en el objetivo.sistema de archivos(por ejemplo, con df) y compararlo con el tamaño de la fuentedividir.
EDITAR:
Para que quede claro: sus 66176851968 bytes son aproximadamente 61,63 GiB. Esto esnomás grande que la partición de origen, que es 62,5 GiB. La fuentedividirno se leyó completamente cuando el objetivosistema de archivosse llenó.
En caso de que no esté familiarizado con la distinción GB/GiB, leaman 7 units.
EDITAR 2
Ahora tenemos todos los números reales. Sigamos con la unidad de 512B, es un tamaño de sector común.
- Su
sdb1dividirOcupa131074048-2048=131072000unidades en el disco. Llamemos a estoP1. Esto es degdiskla salida. - Su
sdb2dividirOcupa262889472-131074048=131815424unidades en el disco. Déjalo serP2. Esto también proviene degdiskla producción. - Susistema de archivosEn el interior
sdb1se pueden almacenar archivos hasta128753336unidades en total. Llamemos a este númeroF1. Esto es dedfla salida. - Susistema de archivosEn su interior
sdb2se pueden almacenar hasta129484424unidades. Déjalo serF2. Esto también proviene dedfla producción.
La diferencia entre P1y F1, así como la diferencia entre P2y F2, se puede explicar si sabes que debe haber espacio para los metadatos. Esto se menciona anteriormente en esta respuesta.
Intentaste ddcopiar todosdb1 dividir, es decir P1, de datos, en un archivo que ocupa el espacio proporcionado por elsistema de archivosinterior sdb2, es decir, F2de espacio disponible.
P1> F2– esta es la respuesta final.Su archivo de imagen no creció más de lo que debería. Me parece que esperabas que su tamaño fuera F1. De hecho toda la imagen tendría un tamaño de P1unidades.
P2y F1son irrelevantes en este contexto.
Respuesta2
Después de esa larga discusión me di cuenta de lo que quieres decir.
Finalmente llegamos al punto. Bueno, mi pregunta era un poco oscura inicialmente antes de editarla. ¡De verdad gracias!
Encontré este comando para obtener el tamaño exacto de las particiones en bytes:
root@sysresccd /root % parted /dev/sdb unidad B p
Modelo: ATA WDC WD1600AAJS-0 (scsi)
Disco /dev/sdb: 160041885696B
Tamaño del sector (lógico/físico): 512B/512B
Tabla de particiones: msdos
Banderas de disco:
Número Inicio Fin Tamaño Tipo Sistema de archivos Banderas
1 1048576B 67109912575B 67108864000B arranque primario ext3
2 67109912576B 134599409663B 67489497088B primario ext3
4 134600457216B 154668105727B 20067648512B extendido
5 134600458240B 150410887167B 15810428928B extensión lógica4
6 150411935744B 154668105727B 4256169984B intercambio lógico de Linux (v1)
3 154668105728B 160041009151B 5372903424B grasa primaria32 lba
Básicamente, necesito comparar el tamaño real de sdb1 (N1) en esta lista con el espacio disponible en sdb2 (N2) en esta lista.
Pero para eso usamos el comando POSIXLY_CORRECT=1 df en el sistema de archivos de destino (sdb2), que era: 129484424 512b-blocks en este caso.
Si dividimos 67108864000B de sdb1 por 512 b = 131072000 512b-blocks. O podemos multiplicar 129484424*512 = 66296025088 Bytes.
Entonces 66296025088 bytes (espacio disponible en sdb2) <67108864000 bytes (tamaño sin formato de sdb1). Es evidente que la imagen de la partición sdb1 no cabe en el espacio disponible en sdb2. Y hay un espacio reservado para ROOT en sdb2 que también conviene tener en cuenta.
Y a partir de mi pregunta sobre el archivo de imagen más grande que la partición, básicamente comparé el tamaño del sistema de archivos sdb1 con la imagen DD en lugar del tamaño de la partición sin formato que DD leerá en su totalidad. ¿Correcto? Incluso puedo aproximar cuánto espacio necesito para que se complete la operación: 66,176,851,968 bytes era el tamaño de la imagen DD incompleta, así que la comparo con el tamaño de la partición sdb1 sin formato 66,176,851,968 = 66176851968 B < 67108864000 B = más pequeño en 932012032 Bytes = 888 MiB
Pero bueno, ¿qué hay ahí en la partición vacía? ¿Metadatos y espacio reservado para root? Tanto espacio???!!!!! ¡¡Muchas gracias!!
Que bueno saber todo esto!!