[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lenny install.Probleme



On Mon, Nov 22, 2010 at 03:57:15PM +0100, David Raab wrote:
> > Falls du Interesse daran hast, dein Setup komplizierter zu machen, 
> > gerne.
> Ich empfehle es, weil es einfacher wird. Man muss zwar neue Befehle
> kennen lernen, im großen und ganzen wird aber vieles so viel einfacher.

Einfacher als maximal einfach (Mein Vorschlag: einmal vernünftig
partitionieren und dann nicht mehr herumoptimieren) ist ziemlich
unmöglich, vor allem wenn man dazu noch LVM lernen muss, wenn man nicht
mal normale Partitionen versteht.

> Wie Jochen Schulz schon sagte ärgere ich mich auch das ich mich mit LVM
> nicht schon viel früher auseinander gesetzt habe.
> 
> Im Debian Installer ist das auch kein Problem. Eine Partition anlegen
> und die Partition als Typ "LVM Raw", oder "LVM Physical" oder ähnlichem
> auswählen. VG und LVs kann mann konfigurieren, das geht auch schon mit
> Lenny.

Na gut, überzeugt. Zumindest wenn es auch funktioniert.

> 
> > - Was ist der Vorteil? Änderst du ständig etwas? Fügst du jede Woche 
> >   eine neue Platte hinzu?
> 
> Ständig nicht, aber es kommt vor, ja. Und wenn es vor kommt ist es Gold
> wert. Zum anderen muss/sollte man mit LVM anders umgehen als mit einem
> festen Partitionierungsschema.
> 
> Ich teile Partitionen immer nur so viel zu wie nötig. Der Rest bleibt
> erstmal frei verfügbar.
> 
> Der Vorteil:
> 
> Jede Partition (in LVM heißt das LV und werde nur noch LV dafür nutzen)
> ist nachträglich erweiterbar, wenn man es irgendwo benötigt.

Nunja. Ich habe eine Partition für mein Desktop System, solange ich
denken kann und damit keine Nachteile. Ich muss also nichts erweitern.

> 
> Man kann ständig neue LVs erzeugen. Zum Beispiel

> * Neues Dateisystem testen? Neue LV zum testen erzeugen

Brauchen ich und diejenige Person, der hier LVM empfohlen wurde, absolut
nicht. Ich verwende ext3, was top-stabil ist. (Ich persönlich habe noch
keine schlechten Erfahrungen damit gemacht)

> * Vorhandene Daten auf neues Dateisystem migrieren? Neue LV mit neuem FS
> erzeugen, Daten kopieren, alte LV löschen. Habe so selber damals meine
> ganzen Daten von ext3 nach XFS migriert.
> * Ich nutze KVM für die Virtualisierung für Testsysteme etc. jedes
> Gastsystem bekommt eine LV. Das ist zum einen die wohl performanteste
> Möglichkeit, zum anderen auch nachträglich gut erweiterbar.

dd if=/dev/zero count=0 bs=1024 seek=$((10 * 1048576)) \
of=~/vm/neuepartition-zum-testen

Ich sehe nicht, wo diese Methode hier irgendeinen relevanten oder
irrelevanten Nachteil hätte. Erweiterbar ist die genauso, von 10 auf
20GB mit der selben zeile:

dd if=/dev/zero count=0 bs=1024 seek=$((20 * 1048576)) \
of=~/vm/neuepartition-zum-testen

> * Neues OS aufsetzen zum testen seperat. Ich habe beispielsweise Debian
> Squeeze einfach mal so testweise aufgesetzt. Dafür hat Squeeze einfach
> neue LVs bekommen. Kann jederzeit Lenny löschen und den frei gewordenen
> Platz wieder anderen Systemen zuteilen.

Hin und wieder mach ich das auch, mit obiger Methode.

> * Einbau neuer platten oder Migration auf neue Festplatte? Einfach neue
> Platte einbauen und mit "pvmove" kannst du einfach daten von einer Disk
> auf die neue schieben.
> * Da logische namen keine Probleme mit /etc/fstab etc. Und keine
> unlesbaren UUIDs etc.

Mein Name ist der wohl logischste, ich kann ihn selbst mit User-Rechten
geben und muss nicht auf irgendwelche Kernel-Action zurückgreifen.

> 
> Dazu kommen Sachen wie Snapshot Funktionalität und jeder andere kram den
> ich wahrscheinlich vergessen habe.

Ich würde mal behaupten, Snapshot Funktionalität ist wesentlich davon
abhängig, wie das jeweilige FS damit zurechtkommt, im gemounteten
Zustand kopiert zu werden oder? Ich benutze hier wie immer dd.

> 
> > - Was machst du, wenn mal ne Platte abraucht (das ist bei mehreren 
> >   Platten schließlich wahrscheinlicher)
> 
> Da ändert LVM nichts dran. Wenn eine festplatte abraucht egal ob du sie
> mit LVM genutzt hast oder nicht sind die Daten futsch.

Das Argument hat sich auf das erhöhte Risiko bezogen, ein FS auf zwei
physische Platten zu verteilen.

> 
> > - Was hast du davon, deine Animes von deinen Comics zu trennen?
> Naja, hast du nicht Persönlich auch getrennte Ordner für
> unterschiedliche Medien? Ein Ordner "musik", ein order "anime" etc.? Mir
> lag es nahe daraus jeweils eine eigene LV zu haben. So hat man auch
> besseren überblick über die entwicklung in größe etc.
> 
> Wer möchte kann natürlich auch eine große LV nehmen wo alle seine Daten
> drauf liegen. Ist wohl geschmackssache. Hatte das Schema davor fande
> aber die Trennung in einzelne LVs flexibler.

Was ist hier flexibel? Du musst mir noch den Vorteil nennen. Einen
Vorteil bekommt man jedenfalls, wenn man lediglich eine Trennung
Nutzdaten/System (zwei Partitionen insgesamt) hat: Einige Kommandos
nehmen so eine Option wie --stay-on-same-filesystem oder so. Oder auch:
NFS exportiert standardmäßig nicht andere Dateisysteme, die unterhalb
des exports gemountet sind (mit guten Grund, finde ich). Hier müsstest
du also jedes deiner Verzeichnisse separat exportieren.
Genauso habe ich keine Lust, jeden Unterordner separat zu mounten.

> > - Ich vermute mal stark, dass dein LVM vom Kernel oder Userland 
> >   gemanaged wird. Was machst du, wenn etwas kaputt geht?
> Was sollte wo kaputt gehen? LVM wird von Kernel und userland verwaltet.
> genauso wie ein iptables oder andere dinge auch. Du kannst jederzeit zum
> Beispiel auch eine Knoppix einlegen und es nutzen etc. Was soll also
> genau wo kaputt gehen?

Damit meinte ich einfach nur, dass eine Rettungsaktion möglicherweise
schwierig gestalten könnte (Ich weiss nicht, wo die Konfiguration für
ein LVM liegt). Eine Partitionstabelle liegt immer am Anfang der
Festplatte und funktioniert. Aber wenn eine LV angeblich schon aus dem
Debian Installer wieder einfach zu mounten ist, gut.

> > Eine MS-Dos-Partition gilt es einmal einzurichten, am besten so, dass 
> > wenig Platz verschenkt wird, 
> Genau das ist ja das Problem, du weist es vorher nie wo Platz mal
> gebraucht wird. Und du bist auch in zukunft deutlich flexibler. Ich habe
> beispielsweise Squeeze parallel aufgesetzt und es genutzt. Die LVs für
> Lenny kann ich löschen, und habe den Platz wieder für andere LVs zur
> verfügung. Mit der MS-DOS partitionierung ist sowas volkommen unmöglich.

Meine Platte hat 360GB und ist damit nach heutigen Maßstäben nicht mehr
riesig. 70GB bekommt mein Standard-System, weitere 70GB für eine WinXP
Partition (wird ganz selten mal zum Spielen benutzt, aber ich hab den
Platz ja), und der Rest für etwaige "Testsysteme", falls KVM nicht
reicht. Da ein Zweitsystem eh keinen wirklichen Sinn macht, denke ich,
wir können mal 10GB veranschlagen, die dafür ausreichen sollten. Wenn
ich richtig gerechnet habe, kann ich also insgesamt 22 Testsysteme auf
meine Platte installieren. Reicht das nicht? (Ok, ich glaube Ms-Dos
Partitionen darf man nur 16 haben).

Achso, falls du dich fragst wo meine Nutzdaten sind (Ich benutze das
Wort `Nutzdaten' nur ungerne, weil wir uns denke ich alle einig sind,
dass in der Größe relevante `Nutzdaten' bei den meisten zu 90% Kopien
von fragwürdiger Legalität sind, und/oder nicht wirklich `genutzt'
werden, sondern einfach nur die pervers große Platte rechtfertigen
sollen):
Die werden natürlich per NFS gemountet. Ich benutze zwar fast nur mein
Hauptsystem, aber mit NFS bin ich einfach "deutlich flexibler" ;-). Und
kann es außerdem mehrfach mounten, wofür normale FS nicht vorgesehen
sind.

Also nichts gegen eine vielleicht ganz hübsche Idee, aber ich denke von
der praktischen her Seite spricht wirklich nichts dagegen, einem User,
der wissen möchte wie sein System aufzusetzen ist, die einfachste
Methode zu empfehlen, die keine essentiellen Nachteile birgt. Wenn es
wirklich darauf ankommt, die letzten GB herauszuquetschen, kommt man
vielleicht ein Stück weiter mit LVM (Aber bestimmt nicht, wenn jeder
Unterordner ein eigenes LV ist).


Reply to: