LVM <-> Partition umwandeln

[warhammer]

Hallo,

ich frage mich gerade welche Möglichkeiten es gibt eine normale Partition in ein LV zu wandeln und umgekehrt.
Mir sind nur zwei Möglichkeiten eingefallen:
1.) Backup der Daten, löschen und entsprechend neu anlegen
2.) Backup der Daten, LV/Partition verkleinern, im freien Platz Partition/LV anlegen, Daten kopieren, LV/Partition verkleinern...

Gibt es sowas wie ein direktes migrieren einer Partition in ein Logical Volume und zurück?

[DeletedUserReAsG]

Gibt es sowas wie ein direktes migrieren einer Partition in ein Logical Volume und zurück?

Kommt drauf an. Übergibst du öfter mal mittels dd Daten byteweise an einen Hexeditor, sortierst Bits um und setzt Flags neu, bevor du sie an eine vorher berechnete Stelle wieder schreibst? Wenn nicht, dann ist die Antwort wahrscheinlich: Nein. Mir ist zumindest kein Programm bekannt, das Daten zusammensammelt, aufteilt, ins RAM schiebt, schaut, wo sie in der neuen FS-Struktur angeordnet werden, dort befindliche Daten einliest, den ersten Datensatz schreibt, die gerade gelesenen Daten an ihre Stelle ins FS schreibt, nachdem es die dort befindlichen Daten gelesen hat, usw. usf.

Deine beiden Möglichkeiten sind schon mit die sinnvollsten Verfahren. Je nachdem, was man erreichen möchte. Empfehlenswert ist es, dabei nicht das reguläre Backup zu überschreiben, sondern einen anderen Datenträger herzunehmen.

sry für’s Gefasel,
niemand

[Cae]

Da LVM die Daten in Chunks speichert, gehe ich mal davon aus, dass man physikalisch ueberhaupt keine zusammenhaengende Partition hat. Entsprechend waere bei einem Umwandlungsprozess zwischendrin fuer laengere Zeit sowohl das LVM als auch das Dateisystem kaputt. Sowas will man einfach nicht, selbst wenn's eine Recovery-Funktion gaebe.

Also "wegsichern und neu machen". Man sollte darauf achten, dass die Platte nicht ihren "winzigen" max. 64 MB [1] grossen Cache vollliest und dann den Kopf auf die Schreibspur bewegen muss, was *nicht* schnell oder effizient ist. Durch einen weiteren Datentraeger umgeht man das Problem, der sollte aber nicht unbedingt langsamer als USB 3.0/SATA sein. Wenn man direkt kopiert, sollte das Kopierprogramm moeglichst viel RAM zum Cachen nehmen. Allerdings sind mir weder bei cp noch bei rsync [2] entsprechende Parameter bekannt, man muesste wohl den Umweg ueber z.B. tar gehen:

Code: Alles auswählen

# tar c {src} | dd bs=2G | tar x -C {dst}

dd liest dann in 2GB-Haeppchen aus dem ersten tar, welches den Quellpfad {src} in ein Archiv packt und dieses in die Pipe schreibt. Sobald der Cache von dd vollgelaufen ist, entpackt das zweite tar diesen Teil des Archivs in den Zielpfad {dst}. Problematisch ist, dass tar keine ACLs kann, die waeren dann einfach kaputt.

Gruss Cae

[1] das ist bei 500 GB Plattenkapazitaet aufwaerts ueblich. Darunter sogar noch weniger Cache
[2] -B scheint etwas anderes zu sein

[dendro]

Zumindest ein Utility zur in-place-Konversion habe ich gerade gesehen:
https://github.com/g2p/blocks#readme

Dies nur zur Auflösung des Pessimismus, den Antwort 2 vor zwei Jahren anklingen ließ ,-)