Größe von Datenbestand ermitteln/schätzen zur Verwendung mit dd

[Tanne]

Hallo,
ich möchte meinen bisherigen Datenbestand von einem Linux auf einen anderen Datenträger/anderes Linux übertragen (beide ext4). Ich möchte dabei die crtime erhalten. Mein bisheriger Datenbestand sind knapp 20 GiB (mit df -B1 und dann umgerechnet) auf einer knapp 28 GiB Partition (auch hier bytes ermittelt und dann umgerechnet), die auf eine leere 125 GiB-Partition übertragen werden muss. Um die crtime zu erhalten, möchte ich die Daten mit dd übertragen, sowas wie

sudo dd if=/dev/sda1 of=/dev/sdb1 bs=16M

Dabei werden ja die knapp 30 GiB übertragen, d.h. 10 GiB verschwendeter Platz. Daher würde ich danach die ca. 10 GiB mit Nullen überschreiben wollen, damit ich sie weiter nutzen kann:

 sudo dd if=/dev/zero of=/dev/sdb1 seek=20G bs=1M count=10240

Allerdings sind das grobe Zahlen, ich würde es genauer machen wollen mit

sudo dd if=/dev/zero of=/dev/sdb1 seek=$(df -B1 /dev/sda1 | awk 'NR==2 {print $2}') bs=1M count=$(( $(df -B1 /dev/sda1 | awk 'NR==2 {print $3}') / 1024 / 1024 ))

.
Allerdings dachte ich daran, für das seek noch was draufzuschlagen, um sicherzugehen, dass keine Daten verloren gehen (verschiedene Kommandos/Berechnungen führen zu unterschiedlichen Ausgaben) (beim Partitionieren muss man ja auch was draufschlagen). Oder gibt es Kommandos, auf deren Ausgabe man sich 100% verlassen kann? Ansonsten: Was wäre in Euren Augen ein angemessener Wert zum Draufschlagen? Und was wäre beim 2. Befehl ein guter Wert für bs (damit es nicht ewig dauert)?
(und seht ihr Fehler in dem Kommando?)
Danke sehr!

 

[schneup]

Nicht mit dd aber in diesem Thread (Unix Stackexchange) werden alternative Moeglichkeiten beschrieben Daten unter Beibehaltung der crtime zu kopieren. Vielleicht ein Versuch wert da diese direkt auf Fileebene arbeiten.

 

[kieleich]

...das macht kein Sinn. Du schreibst da Nullen in eine Partition rein ohne zu wissen wo das Datei System überhaupt die Daten abgelegt sein die können am Anfang sein am Ende oder mitten zwischen drin, Datei Systeme schreiben nicht fein säuberlich von sektor 0 bis mitte

das Ergebnis vom blind rein schreiben ist einfach nur ein kaputtes Datensystem nachher

und bs ist immer bs=1M und das bringt auch nur was weil der default bs=512 byte einfach steinzeit ist

wenn du freien speicher nullen willst dann kannst du das eher mit fstrim erreichen, klappt aber auch nur auf SSD die read zero after trim haben und davor nochmal caches leeren. wenn es kein SSD ist dann schreib die kopie als datei "sdb1.img" und dann fstrim aufs loop-mount solange das dateisystem punch-hole unterstützt hast du dann die nullen/löcher im sdb1.img

bzw wenn die nullen schon in der quelle sind, mit dd conv=sparse kopieren, aber das nur für dateisystem images, nicht geeignet für of=/dev/ weil sonst alte daten, da stehen wo nullen sein sollten dd unterscheidet nicht, löcher-null vs. absicht-null

 

[xammu]

Rsync hat eine Option dafür "--crtimes"

"...
--crtimes, -N,
This tells rsync to set the create times (newness) of the destination files to the same value as the source files. Your OS & filesystem must support the setting of arbitrary creation (birth) times for this option to be supported.
..."

 

[Habicht]

Hallo,
ich möchte meinen bisherigen Datenbestand von einem Linux auf einen anderen Datenträger/anderes Linux übertragen (beide ext4).

Dafür ist dd das falsche Tool, so etwas macht man mit rsync.

 

[Tanne]

Nein, rsync war auch meine erste Idee, aber die Option geht leider nicht unter Linux. Als nächstes schaute ich mit debugfs, was auch im Thread von @schneup verwendet wird. dort gibt es set_inode_field, crtime ist leider nicht bei den änderbaren Feldern dabei (keine Ahnung, wieso das in dem Thread anders war).
Irgendwann kam ich auf die Idee mit dd und befragte ein LLM dazu. Dort tüftelten "wir" die obige Strategie aus (ich bin nicht wirklich Fan von LLM's, aber in der Not nutze ich es dann halt doch...). Das LLM sagte, auch auf explizite Rückfrage, dass die Daten an den Anfang geschrieben werden und danach würden die leeren Blocks geschrieben (sonst würde das mit dem seek ja keinen Sinn machen). Aber wird wohl ein weiteres Ding sein, wo das LLM falsches Zeug sagt. Zum Rest von @kieleich s Beitrag muss ich erstmal länger überlegen was ich schreib bzw. versteh ich es nicht. Im Grunde geht es mir ja darum, die Daten so zu übertragen, dass crtime erhalten bleibt, das mit dd war nur ein Lösungsversuch. (im Internet hab ich dazu auch keine Lösung gefunden, alle suchen nur)

 

[Habicht]

Vielleicht hab ich es ja überlesen - du willst doch das Erstellungsdatum erhalten oder um was genau geht es hier.

 

[Tanne]

Genau, das Attribut crtime (creation time)

 

[Habicht]

Aber das macht doch rsync - alle meine Daten auf meiner Datensicherung haben ihr Erstellungsdatum behalten, dafür brauch es noch nicht mal besondere Optionen.

 

[wern001]

Dafür ist dd das falsche Tool, so etwas macht man mit rsync.

Würd ich auch sagen.
dd ist für eine sektorkopie der platte. Da ist es egal was drauf ist. Ideal um auch Linuxfremde Datenträger zu kopieren/klonen.

 

[Tanne]

Ich hab rsync doch probiert, statt des alten Datums wird das Datum vom Ausführen des Befehls gesetzt (also crtime wird auf mtime gesetzt). Und mit der Option kommt eine Fehlermeldung. Das ist wohl allgemein bei Linux, es funktioniert bei macOS und ich glaube bei anderen Dateisystemen wie btrfs und noch eins. Aber mit ext4 unter Linux eben nicht. (ich muss jetzt erstmal aufhören, ich guck später nochmal rein)

 

[foofoobar]

Danke sehr!

Du kannst nicht davon ausgehen das nur der "vordere Platz" belegt ist und crtime scheint (nach kurz google) ein hartnäckiges Attribut zu sein.

Wahrscheinlich bist du mit einem vorherigen resize2fs und nach dem dem kopieren einem weiteren resize2fs am besten bedient, und damit sollten deine (wahrscheinlich komischen) Anforderungen erfüllt sein.

"cp --sparse=always" könnte auch eine Möglichkeit sein, oder schnell mal den C-Compiler anwerfen und alle Haufen von Nullen durch ein seek ersetzen.

 

[Looniversity]

Aber mit ext4 unter Linux eben nicht

Dafür könnte man glatt einen Bugreport erstellen, sofern das nicht doch irgendein obskures aber gewolltes (??) und dokumentiertes Verhalten ist.

 

[Habicht]

Ich hab rsync doch probiert, statt des alten Datums wird das Datum vom Ausführen des Befehls gesetzt

Komisch, bei mir nicht - Daten aus 2015 haben auch 2015 als Datum in der Sicherung.

rsync -av --progress QUELLE ZIEL

und übrigens alles unter ext4.

 

[Tornhoof]

Crtime kann von rsync nicht gesetzt werden, es gibt kein syscall der btime (so heißt es in der Kernel Nomenklatur) setzen kann.

https://lkml.org/lkml/2025/3/10/909


Wenn man sich also
https://unix.stackexchange.com/ques...irectories-on-ext4fs-filesystem/591406#591406

Durchliest, ist's entweder star als tool, das setzt vor jedem Schreiben die Systemzeit auf das richtige Datum oder man bastelt mit debugfs rum. Wenn du mutig bist kannst ja das Script in dem thread probieren, ansonsten ist ziemlich sicher der sicherere weg die Zeitstempel in eine Datei zu schreiben, das fs zu unmounten und dann die Zeitstempel schreiben. Steht auch so im thread oben drin.

@Habicht ggf ist's bei dir der mtime, das kann gut überlappen.

 

[Habicht]

@Habicht ggf ist's bei dir der mtime, das kann gut überlappen.

Keine Ahnung - sicher weiß ich nur, dass das Erstellungsdatum erhalten bleibt.

mtime, ctime, atime - Was sind die Unterschiede?​

Unter Linux besitzt jede Datei 3 Zeitstempel: mtime, ctime und atime.

• atime (access time) ist der Zeitpunkt des letzten Lesezugriffs.
• ctime ist der Zeitpunkt der letzten Änderung an der Inode der Datei
• mtime ist der Zeitpunkt der letzten Änderung am Inhalt der Datei

mtime und ctime ändern sich immer wenn etwas am Inhalt der Datei gemacht wird. ctime ändert sich auch, wenn z.B. der Besitzer der Datei geändert wird, am Inhalt jedoch nichts gemacht wird.

rsync ändert ja nichts am Inhalt der Datei - ich kann mir jetzt eigentlich nur noch vorstellen, dass sich im vorliegenden Fall der Besitzer ändert.

 

[foofoobar]

Ich sehe gerade dd hat auch eine sparse option:

       sparse try to seek rather than write all-NUL output blocks

 

[kieleich]

Ja aber die solltest du nicht verwenden beim Schreiben auf Blockgeräte, es sei denn du garantierst das es vorher genullt war

Sonst hast du irgendwelche alten Daten da wo nullen sein sollen. Manche Dateiformat haben mit absicht genullte bereiche was aber keinen freien Speicher dar stellt. dd sparse würde das überspringen und so würden alte daten an dieser stelle stehen statt der erwarteten null

bei einer (neuen) imagedatei ist es kein problem, bei dateien ist alles null was nicht geschrieben wurde

 

[foofoobar]

Ja aber die solltest du nicht verwenden beim Schreiben auf Blockgeräte, es sei denn du garantierst das es vorher genullt war

Und fstrim kann bei einem neuen Speichertyp vielleicht 0xff erzeugen :-)

Aber der TO hat jetzt sicherlich erstmal Futter zum verdauen :-)