staging.inyokaproject.org

xChaosX schrieb:

mir ist eben ein Fehler bei dieser Stelle aufgefallen:

Danke, korrigiert.

Das Wiki ist aber auch zum Mitmachen und sowas darf gerne selber geändert werden.

Eigentlich muss das ohne -d gehen.

$ echo Hallo Welt | gzip > hallo.gz
$ gunzip -c hallo.gz 
Hallo Welt
$ gunzip -cd hallo.gz 
Hallo Welt
$ gunzip -c hallo.gz | dd 
Hallo Welt
0+1 records in
0+1 records out
11 bytes copied, 0.000785302 s, 14.0 kB/s
 $ gunzip -cd hallo.gz | dd 
Hallo Welt
0+1 records in
0+1 records out
11 bytes copied, 0.000785913 s, 14.0 kB/s

In der Manpage steht auch:

zcat  is  identical  to  gunzip  -c.

Bei gzip bräuchtest du -d. gzip packt, gunzip entpackt. gunzip führt dabei eigentlich nur gzip -d aus. Es ist also ein Alias, wie zcat auch. (Vergleiche tail /bin/gunzip, tail /bin/zcat, das sind Shellscripte)

Scheiße, nicht aufgepasst.

Hi, gehe ich recht in der Annahme, dass der freie Speicherplatz auch 1:1 kopiert- und dementsprechend nicht genullt wird? Falls ja, wäre es vielleicht interessant darauf hinzuweisen. Immerhin wären dann ja auch Datenrettungsversuche aus der Kopie heraus möglich.

Respektive würde man die Kompression von einem Image verbessern, wenn man den freien Platz vorher nullt, oder sehe ich das falsch?

Kerlbürste_Suessholz schrieb:

Hi, gehe ich recht in der Annahme, dass der freie Speicherplatz auch 1:1 kopiert- und dementsprechend nicht genullt wird?

Weiß nicht worauf du dich jetzt genau beziehst - dd hat kein Konzept von "freien Speicherplatz", da wird das gesamte Blockgerät kopiert.

Falls ja, wäre es vielleicht interessant darauf hinzuweisen. Immerhin wären dann ja auch Datenrettungsversuche aus der Kopie heraus möglich.

Klar, deswegen macht man das ja auch oft so (?) - nur bei Hardwarefehlern (unlesbaren Sektoren) stattdessen ddrescue nehmen.

Respektive würde man die Kompression von einem Image verbessern, wenn man den freien Platz vorher nullt

Ja, wobei es zumindest für Linux eh besser ist die Dateien zu sichern als Images zu machen.

hab mal die uralten requirements aus dd (Abschnitt „Live-USB-Stick-erstellen“) entfernt. Inhaltliche Frage: Geht das so auch mit UEFI oder wird da zwingend EFI USB-Stick benötigt?

Ein mit dd erstellter USB-Stick funktioniert auch bei UEFI-Systemen. Aber dadurch, dass das DVD-Dateisystem auf den Stick geschrieben wird, ist dieser dann nicht mehr beschreibbar und hat auch nur die Größe des ISO. Wenn man den Stick wieder als beschreibbaren Datenträger verwenden will, muss man eine neue Partitionstabelle erstellen. Dabei hatten wohl einige User Probleme und es wurde gelegentlich behauptet, dass der Stick durch das Beschreiben mit dd zerstört worden wäre.

Im Wiki-Artikel steht in der ersten Warnbox an dritter Stelle:

„Zur Übernahme eines bestehenden Systems auf eine SSD (Solid-State-Drive) sollte dd nur mit äußerster Vorsicht genutzt werden.“

Die dann folgenden Begründungen bezüglich der Blockgröße und des Alignment erscheinen mir zwar plausibel, verunsichern mich aber auch, weil verschwiegen wird, wie ich denn die für meine SSD passenden Parameter herausfinden kann.

Fragen:

1. Gilt dieser Warnhinweis überhaupt noch für aktuelle SSDs?

2. Wie finde ich die angemessenen Parameter für Blockgröße und Alignment heraus, wenn die SSD vor mir liegt?

3. Gilt die Warnung auch für USB-Sticks bzw. -Disks, da diese ja auch Flash-Speicher enthalten?

(Konkrete Anwendung soll der Transfer einer Partition von einer HDD auf eine SSD sein.)

kB schrieb:

Gilt dieser Warnhinweis überhaupt noch für aktuelle SSDs?

Alignment hängt davon ab, welches Alignment auf der HDD gegeben ist. dd kann von sich aus ja schlecht irgendwelche Alignments ändern.

Ansonsten sollte man bei dd sowieso immer bs=1M nehmen. Ansonsten bleibt nur das Problem, daß die SSD nach dd nicht weiß, was freier Speicher ist - bei Bedarf fstrim hinterher und gut.

Läßt man das bs=1M weg und kopiert also mit dem bescheuerten Standard von 512 Bytes... da kann es sein, daß der Kernel das stillheimlich im Hintergrund in größere Requests zusammenfasst und die SSD somit nie so kleine Schreibzugriffe sieht. Leider ist das schwer nachzuvollziehen / zu kontrollieren.

Wenn die SSD leer war (also nach komplettem TRIM / blkdiscard) machen ihr auch kleine Schreibzugriffe relativ wenig aus. Dann hat die SSD vielleicht selber noch einen Schreibcache, das ist dann letztlich Sache der SSD was sie draus macht.

Solange man das ganze nicht jeden Tag sondern nur einmal macht, dürfte es so oder so keine Rolle spielen.

Dabei hatten wohl einige User Probleme und es wurde gelegentlich behauptet, dass der Stick durch das Beschreiben mit dd zerstört worden wäre.

USB Stick mit dd zerstört kann schon mal passieren. USB Sticks / Speicherkarten sind noch viel schlechter dran als SSDs, weil die meistens kein brauchbares Wear-Leveling und schon gar keine TRIM-Unterstützung haben. Und die winzig kleinen USB Sticks die kaum aus dem USB Port hervorschauen, und manche MicroSDs, werden unter Last viel zu heiß und sterben dann zusätzlich noch den Hitzetod.

Das sind dann eben Speichermedien mit kurzer Lebensdauer / hohem Verschleiß, bzw. einfach nicht auf Dauerlast ausgelegt sondern für dann und wann mal ne kleine Datei draufspielen und sonst idle.

Im Wiki-Artikel heißt es:

Es sollte darauf geachtet werden, dass die beiden Festplatten gleich groß sind - oder zumindest das Ziel größer. Auch die Sektorengröße (512 Bytes oder Advanced Format mit 4096 Bytes) muss bei Beiden identisch sein.

Wieso muß die Sektorengröße bei beiden Identisch sein?

Was soll man sonst machen, wenn die Sektorengröße nicht gleich ist?

Beispiel Source:

administrator@workstation:~$ sudo hdparm -I /dev/sdc
[sudo] Passwort für administrator:

/dev/sdc:

ATA device, with non-removable media
Model Number: ST3320620AS
Serial Number: 9QF1HE1B
Firmware Revision: 3.AAC
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 625142448
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 305245 MBytes
device size with M = 1000*1000: 320072 MBytes (320 GB)
cache/buffer size = 16384 KBytes
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
Device-initiated interface power management
* Software settings preservation
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase

Beispiel Destination:

administrator@workstation:~$ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
Model Number: WDC WD2000F9YZ-09N20L1
Serial Number: WD-WMC5C0D01SWS
Firmware Revision: 01.01A02
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 3907029168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 1907729 MBytes
device size with M = 1000*1000: 2000398 MBytes (2000 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: 7200
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
* 48-bit Address feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
unknown 119[7]
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
* Idle-Unload when NCQ is active
* NCQ priority information
* READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
* DMA Setup Auto-Activate optimization
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Write Same (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
unknown 206[7]
unknown 206[12] (vendor specific)
unknown 206[13] (vendor specific)
unknown 206[14] (vendor specific)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
228min for SECURITY ERASE UNIT. 228min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50014ee0040fdbc4
NAA : 5
IEEE OUI : 0014ee
Unique ID : 0040fdbc4
Checksum: correct

Ausführung von dd:

administrator@workstation:~$ sudo dd if=/dev/sdc of=/dev/sdb bs=1M
[sudo] Passwort für administrator:
Das hat nicht funktioniert, bitte nochmal probieren.
[sudo] Passwort für administrator:
305245+1 Datensätze ein
305245+1 Datensätze aus
320072933376 bytes (320 GB, 298 GiB) copied, 4859,63 s, 65,9 MB/s

superhonk schrieb:

Wieso muß die Sektorengröße bei beiden Identisch sein?

Wird sich wohl vorrangig aufs Alignment beziehen. Die meisten Laufwerke arbeiten (auf logischer Ebene) ja weiterhin mit 512 Byte Sektoren, insofern ändert sich da "nix", funktioniert alles, aber wenn das Alignment nicht stimmt, ist die Performanz im Eimer.

Richtige Probleme fangen an wenn ein Laufwerk auch logisch mit 4K oder größer unterwegs ist. Da stimmt dann die Partitionstabelle nicht mehr und muss neu geschrieben werden (was nur geht, wenn die Partitionen ins Alignment passen). Und es gibt Bugs/Probleme wie hier https://www.spinics.net/lists/raid/msg61070.html

Was soll man sonst machen, wenn die Sektorengröße nicht gleich ist?

Nicht mit dd kopieren sondern neue Partitionen, Dateisysteme anlegen und Dateien mit rsync -aAHSX odgl. rüberschippern ...

Hi,

im Abschnitt Festplatte (sicher) löschen wird erklärt, wie eine Platte aufwändig mit zufallsgenerierten Daten statt mit Nullen überschrieben werden kann. Wäre nicht ein kleiner Hinweis angebracht, dass dies wahrscheinlich Zeitverschwendung ist?

Zufallsdaten schreiben dauert nicht länger als Nullen schreiben, vorausgesetzt die Zufallsdaten-Quelle ist schnell genug, und /dev/urandom ist zumindest deutlich schneller geworden. Habe mir mal erlaubt da einen Hinweis anzubringen.

Hallo in die Runde,

kB schreibt am 3. September 2018 14:27 hier zum Thema Hybrid-Images

Die modernen ISOs von Ubuntu sind Hybrid-Images, ...

Ich möchte diesen Hinweis unter diesen Befehl schreiben.

sudo dd if=hybrid_iso_image.iso of=/dev/sdx bs=1M && sync 

Er steht im Teil Live-USB-Stick-erstellen

Ist das so o.k?

Berlin_1946 schrieb:

[…] kB schreibt am 3. September 2018 14:27 hier zum Thema Hybrid-Images

Die modernen ISOs von Ubuntu sind Hybrid-Images, ...

Ich möchte diesen Hinweis unter diesen Befehl schreiben.

Aus meiner Sicht ist das O.K., man sollte dann aber auch vermerken, dass MS-Windows-ISOs keine Hybrid-ISOs sind und damit diese Vorgehensweise bei MS-Windows nicht zum Erfolg führt.