Die DD-Ausgabeimagedatei ist größer als die Quellpartition und DD hat auf der Zielpartition (auf der das Image erstellt wird) nicht genügend Speicherplatz, obwohl diese größer als die Quellpartition ist.
Ich versuche, eine Partition in eine Datei auf einer anderen Partition auf derselben Festplatte zu kopieren. Die Zielpartition ist etwas größer als die Eingabepartition. Beide sind ext3Partitionen.
Wird von der OpenSuse-Rescue LIVE-CD ausgeführt. Yast zeigt, dass die Eingabepartition ( sdb1) 62,5 GiB und die Ausgabepartition sdb262,85 GiB groß ist.
Thunar zeigt, dass die Eingabe sdb165,9 GB und die Ausgabe sdb266,2 GB groß ist, während die Ausgabebilddatei ddebenfalls 66,2 GB groß ist, also offensichtlich das Maximum erreicht ist sdb2.
Hier ist die Konsole:
( sdb1wurde abmontiert, ddein paar Mal versucht)
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
Weitere Infos auf Anfrage:
Und noch einmal: Ich sehe den Unterschied in der Größe der Quellpartition sdb1und der RR.imagedaraus erstellten DD-Image-Datei. Diese Datei befindet sich auf sdb2.
Hier ist noch etwas unklar: Ich führe DD als ROOT aus, sodass der reservierte Speicherplatz zum Schreiben verfügbar ist, richtig? Das Ziel sdb2sind 62,85 GiB, während die Gesamtbytes für das Image, wie Sie sagten, etwa 61,63 GiB betragen. Hier ist auch die Ausgabe dfund POSIXLY_CORRECT=1 dfdie Befehle:
Das System ist jetzt 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
dfWenn wir durch 2 teilen, sind die Zahlen genau dieselben wie im einfachen Modus. Der Divisor ist 1024b/512b=2.
sdb1ist kleiner alssdb2. Die 100-prozentige Auslastung vonsdb2liegt jetzt an der DD-Image-Datei, die die Partition gefüllt hat. Es muss jetzt die einzige Datei darauf sein.Die Image-Datei selbst ist laut DD (zur Laufzeit) und Thunar-Berichten 66.176.851.968 Byte groß. Geteilt durch 1024 Byte erhalten wir 64625832 K-Blöcke, richtig? Sie ist also immer noch um mehr als 116380 K kleiner als
dfangegebensdb2und GRÖSSER ALSsdb1(DIE QUELLE), aber sie schöpft die Partition voll aussdb2.
Die Frage ist: Was gibt es da drinnen, um diesen Platz einzunehmen sdb2?
Aber das Wichtigste und Interessanteste ist:
Warum ist die Zieldatei größer als die Quellpartition, ddaus der sie erstellt wurde? Das bedeutet für mich: Ich kann sie nicht zurückschreiben.
sdb1(64376668K) < RR.image(64625832K)
Und
sdb1(64376668 1K-Blöcke) < RR.image(64625832 1K-Blöcke) < sdb2(64742212 1K-Blöcke)
(Ich hoffe, es wurde richtig berechnet…)
Nun habe ich die Blöcke überprüft, die für ROOT reserviert sind. Ich habe diesen auszuführenden Befehl gefunden:
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%
Falls das von Bedeutung ist, ist der für ROOT reservierte Prozentsatz auf beiden Partitionen ebenfalls derselbe.
Hier ist die Ausgabe für 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
Wie groß ist es also tatsächlich sdb1?
Ist sdb2(N2) nicht größer als sdb1(N1)? WARUM WIRD die Image-Datei dann GRÖSSER als sdb2(N2)? Wenn ich den für Root reservierten Speicherplatz ausschalte sdb2, passt es dann dorthin?
Antwort1
Jedes Dateisystem braucht Platz für Metadaten. Außerdem extFamiliereserviert etwas Platz für rootden Benutzerund der Standardwert liegt bei 5 %.
Beispiel
In meinem Kubuntu habe ich eine (sparse) Datei mit 1 GiB erstellt:
truncate -s 1G myfile
und habe ext3darin ein Dateisystem erstellt. Der Befehl war einfach
mkfs.ext3 myfile
Dadurch wurden sofort etwa 49 MB (~5 % in diesem Fall) zugewiesen myfile. Ich konnte das erkennen, weil die Datei spärlich war und zunächst eine Nutzung von 0 MB auf meiner realen Festplatte meldete, dann aber anstieg. Ich nehme an, hier befinden sich die Metadaten.
Ich habe das Dateisystem gemountet; df -h976 MiB Gesamtspeicherplatz wurden gemeldet, aber nur 925 MiB waren verfügbar. Das bedeutet, dass mir weitere ~5 % nicht zur Verfügung standen.
Dann füllte ich diesen Raum (nach cddem Mountpoint) mit
dd if=/dev/urandom of=placeholder
Als normaler Benutzer konnte ich nur 925 MiB verwenden. Die gemeldete „Festplattennutzung“ betrug dann 100 %. Wenn ich jedoch dasselbe wie ein Benutzer machte root, konnte ich 976 MiB in die Datei schreiben. Als die Datei über 925 MiB anwuchs, blieb die Nutzung bei 100 %.
Abschluss
Der Vergleich der Größe Ihrer Partitionen ist in diesem Fall falsch; ebenso der Vergleich der Größe Ihrer Dateisysteme. Sie hätten den verfügbaren Speicherplatz auf dem Ziel überprüfen sollenDateisystem(zB mit df) und vergleichen Sie es mit der Größe der QuellePartition.
BEARBEITEN:
Um es klarzustellen: Ihre 66176851968 Bytes sind etwa 61,63 GiB. Das istnichtgrößer als die Quellpartition, die 62,5 GiB groß ist. Die QuellePartitionwurde nicht vollständig gelesen, als das ZielDateisystembin voll geworden.
Falls Sie mit der Unterscheidung zwischen GB und GiB nicht vertraut sind, lesen Sieman 7 units.
BEARBEITEN 2
Jetzt haben wir alle tatsächlichen Zahlen. Bleiben wir bei der Einheit 512B, das ist eine gängige Sektorgröße.
- Dein
sdb1Partitionbelegt131074048-2048=131072000Einheiten auf der Festplatte. Nennen wir diesP1. Dies ist ausgdiskder Ausgabe. - Dein
sdb2Partitionbelegt262889472-131074048=131815424Einheiten auf der Festplatte. Lassen Sie es seinP2. Dies ist auch ausgdiskder Ausgabe. - DeinDateisystemIm Inneren
sdb1können Dateien bis zu128753336Einheiten gespeichert werden. Nennen wir diese ZahlF1. Dies ist ausdfder Ausgabe. - DeinDateisystemim Inneren
sdb2können bis zu129484424Einheiten gespeichert werden. Lass es seinF2. Dies ist auch vondfder Ausgabe.
Der Unterschied zwischen P1und F1sowie der Unterschied zwischen P2und F2können erklärt werden, wenn Sie wissen, dass Platz für Metadaten vorhanden sein muss. Dies wurde bereits früher in dieser Antwort erwähnt.
Sie ddhaben versucht, das Ganze zu kopierensdb1 Partition, also P1von Daten, in eine Datei, die den vomDateisystemim Inneren sdb2, also F2des verfügbaren Platzes.
P1> F2– das ist die endgültige Antwort.Ihre Bilddatei ist nicht größer geworden als sie sollte. Es sieht für mich so aus, als hätten Sie eine Größe von erwartet F1. Tatsächlich hätte das gesamte Bild eine Größe von P1Einheiten.
P2und F1sind in diesem Zusammenhang irrelevant.
Antwort2
Nach dieser langen Diskussion ist mir klar geworden, was Sie meinen.
Endlich sind wir beim Thema. Nun, meine Frage war zunächst etwas unklar, bevor ich sie bearbeitet habe. Vielen Dank!
Ich habe diesen Befehl gefunden, um die genaue Größe von Partitionen in Bytes zu ermitteln:
root@sysresccd /root % parted /dev/sdb Einheit B p
Modell: ATA WDC WD1600AAJS-0 (scsi)
Datenträger /dev/sdb: 160041885696B
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Datenträger-Flags:
Nummer Start Ende Größe Typ Dateisystem Flags
1 1048576B 67109912575B 67108864000B primärer ext3-Boot
2 67109912576B 134599409663B 67489497088B primär ext3
4 134600457216B 154668105727B 20067648512B erweitert
5 134600458240B 150410887167B 15810428928B logisch ext4
6 150411935744B 154668105727B 4256169984B logischer Linux-Swap (v1)
3 154668105728B 160041009151B 5372903424B Primärfett32 lba
Grundsätzlich muss ich also die tatsächliche Größe von sdb1 (N1) in dieser Liste mit dem verfügbaren Speicherplatz auf sdb2 (N2) in dieser Liste vergleichen.
Aber dafür verwenden wir den Befehl POSIXLY_CORRECT=1 df auf dem Zieldateisystem (sdb2), das in diesem Fall 129484424 512b-Blöcke umfasst.
Wenn wir 67108864000B von sdb1 durch 512 b teilen, erhalten wir 131072000 512b-Blöcke. Oder wir multiplizieren 129484424*512 = 66296025088 Bytes.
Also 66296025088 Bytes (verfügbarer Speicherplatz auf sdb2) < 67108864000 Bytes (Rohgröße von sdb1). Offensichtlich passt das Partitionsabbild von sdb1 nicht in den verfügbaren Speicherplatz auf sdb2. Und es gibt einen für ROOT reservierten Speicherplatz auf sdb2, der ebenfalls berücksichtigt werden sollte.
Und was meine Frage zu der Image-Datei angeht, die größer als die Partition ist, habe ich im Grunde die Größe des sdb1-Dateisystems mit dem DD-Image verglichen, anstatt mit der Größe der Rohpartition, die von DD vollständig gelesen werden soll. Richtig? Ich kann sogar ungefähr abschätzen, wie viel Speicherplatz ich für die Durchführung des Vorgangs benötige: 66.176.851.968 Bytes war die Größe des unvollständigen DD-Images, also vergleiche ich es mit der Größe der Rohpartition sdb1 66.176.851.968 = 66176851968 B < 67108864000 B = kleiner um 932012032 Bytes = 888 MiB
Aber hey, was ist da auf der leeren Partition? Metadaten und für Root reservierter Speicherplatz? So viel Speicherplatz???!!!!! Vielen Dank!!
Gut, das alles zu wissen!!