staging.inyokaproject.org

Hallo,

im Unterabschnitt Logical Volunes erstellen des Artikels Logical Volume Manager wird abschließend auf den Artikel Partionierung verwiesen.

Das ist IMHO nicht zielführend, weil

1. das LV bereits einer Partition entspricht,

2. die Partitionstools - zumindest GParted - mit LVs nicht klarkommen und

3. das LV "nur noch" partitioniert werden muss.

Ein passender Verweis wäre der auf einen Artikel mit allgemeinen Ausführungen zur Formatierung von Volumes, den es nicht gibt bzw. den ich nicht finden kann.

Wie seht Ihr das?

Gruß

Thomas

Hallo!

Weiter oben bei den Vor- und Nachteilen steht:

"Eine zusätzliche /boot Partition außerhalb des LVM-Verbundes ist erforderlich. "

Das stimmt aber nicht mehr. Wird Grub im MBR installiert, kann man auch Betriebssysteme starten, deren /boot-Partiton in einem LVM liegt. Stimmt mir da jemand zu? Dann könnte man das im Wiki mal ändern 😉

Gruß, Pascal

Im wiki steht zum löschen eines logical volumes muss man "sudo lvremove <volume>" eingeben. Das geht aber nicht. Woher soll da auch klar sein, welche volume group benutzt wird?

Müsste da nicht "sudo lvremove <group>/<volume> " stehen?

Aus der manpage: lvremove [-A/--autobackup y/n] [-d/--debug] [-f/--force] [-h/-?/--help] [-t/--test] [-v/--verbose] LogicalVolumePath [LogicalVolumePath...]

Nur den Pfad des LV angeben reicht schon, da der Pfad eines LV nicht in zwei volume-groups sein kann.

Mein System fährt jedenfalls auch weiterhin mit /boot im LVM hoch 😛

Gruß, Pascal

Ja, genau. Was ich meinte ist, dass das auch im Wiki hätte stehen können. 😉

obstriegel schrieb:

Hallo!

Weiter oben bei den Vor- und Nachteilen steht:

"Eine zusätzliche /boot Partition außerhalb des LVM-Verbundes ist erforderlich. "

Das stimmt aber nicht mehr. Wird Grub im MBR installiert, kann man auch Betriebssysteme starten, deren /boot-Partiton in einem LVM liegt. Stimmt mir da jemand zu? Dann könnte man das im Wiki mal ändern 😉

Für GRUB 2 stimme ich zu. Da braucht man dann auch keine eigene Bootpartition innerhalb der LV-Gruppe.

Hast Du das unter Karmic laufen? Und hattest Du bei der Einrichtung irgendwelche Probleme mit GRUB zu umschiffen?

Gruß, Martin

Hey, jemand hat den LVM-Artikel verstümmelt, könnte ein Mod den wiederherstellen?

Hallo,

elektronenblitz63 hat's erledigt. ☺

Gruß, noisefloor

Hallo,

ich bin auch gerade im Wiki über die Formulierung

"Eine zusätzliche /boot Partition außerhalb des LVM-Verbundes ist erforderlich."

gestolpert.

Dazu schrieb Newubunti:

Für GRUB 2 stimme ich zu. Da braucht man dann auch keine eigene Bootpartition innerhalb der LV-Gruppe.

Hast Du das unter Karmic laufen? Und hattest Du bei der Einrichtung irgendwelche Probleme mit GRUB zu umschiffen?

Ich habe ein vergleichbares Setup (root-Partition ohne separate /boot in einem LV) unter Lucid laufen. Keinerlei Probleme bei Installation oder Betrieb.

Die Formulierung im Wiki könnte also auch meiner Meinung nach geändert werden.

VG, ArnoW

Hi. Im Wiki steht:

Nachteile¶

• Der sog. "Single-Point-of-Failure" wird größer, da beim Ausfall einer Platte alle Daten verloren sind, ähnlich wie bei RAID0.

Sollte man nicht nochmal extra darauf hinweisen, dass das nur gilt, wenn sich das LVM über mehrere Platten verteilt und nicht, wenn man nur eine FP hat? Der darauffolgende Hinweis müsste da auch angepasst werden.

Hallo,

habe den Satz mal korrigiert...

Gruß, noisefloor

Joa sieht besser aus.

Danke.

Ein Detail, aber es wird wichtig:

momentan wird die Artikelserie Baustelle/SSD fertiggestellt. Dabei ist das korrekte Alignment von Partitionen auf 1 MiB ein wesentlicher Faktor, um die optimale Leistung und Lebensdauer zu erzielen, s. http://wiki.ubuntuusers.de/Baustelle/SSD/Alignment.

In diesem Zusammenhang ist der "kleine Unterschied" zwischen (dezimalen) MB und (binären) MiB von entscheidender Bedeutung. Hier wird sich dann auch "LVM" beteiligen müssen.

Im Abschnitt Physical Extent ist aber derzeit noch von "die Standardgröße beträgt 4 MByte" die Rede. Das sollte doch sicher korrekt MiB (Mebibytes) heißen? (Details s. Diskussion zu dem Artikel).

Erklärung: 4 MB = 4000 KiB, 4 MiB = 4096 KiB.

Wenn SSD's jetzt immer populäre werden, sollten alle Artikel korrekt mit dem Binären Einheiten arbeiten.

Viele Grüße,
Ingo

ingo2 schrieb:

Erklärung: 4 MB = 4000 KiB, 4 MiB = 4096 KiB.

4 MB = 4000 KiB? Das ist ja mal schräg...

Wenn SSD's jetzt immer populäre werden, sollten alle Artikel korrekt mit dem Binären Einheiten arbeiten.

Hat mit SSD nullkommagarnix zu tun. Und selbst wenn du alle Artikel umstellst, die Software selber verwendet immer noch G oder GB und meint damit 1024er (weil das eh klar ist).

frostschutz schrieb:

ingo2 schrieb:

Erklärung: 4 MB = 4000 KiB, 4 MiB = 4096 KiB.

4 MB = 4000 KiB? Das ist ja mal schräg...

In der Tat - ist eine böse Mischung aus Dezimal- und Binär-Zahlen. Aber es gibt/gab tatsächlich Tools, die so "rechnen". Da wird bis 1 KiB = 1024 Bytes korrekt Binär gerechnet, weil ja die Festplatten 512 Bytes große Sektoren haben, dann ab Mega... wird dezimal weiter gerechnet - brrrr.

Das das Ganze für SSD's uninteressant ist, ist wohl ein Irrtum. Hier ein Kommentar von dir selbst. Das war zwar etwas überzogen, aber es entspricht der Wahrheit.

Viele Grüße,
Ingo

P.S.: wenn wir jetzt im Wiki schon dem Motto "ist doch Wurscht" folgen - wie sollen es dann die User korrekt lernen? Gerade auf diesem Gebiet herrscht ein wahlloses Chaos.