Hallo, in der letzten ct (25/2005) wurde LVM besprochen. Eigentlich ganz interessant. Aber, ich sitzte hier vor einen Einzelplatzrechner, mit zwei großen Festplatten (hat sich so ergeben), mit Windows XP und 64 und 32 bit Linux Varianten, die einfach in getrennten Partionen untergebracht sind. Die eigenen Daten sind, sofern sie nicht von einer bestimmten Linuxversion abhängig sind, auf einer große Datenpartition gelegt und von den "Linuxen", wo benötigt, verlinkt. Bei Wartung hänge ich die Datenpartiton aus. Sollte ich z.B. ein größers /tmp Verzeichnis brauchen, kann ich das doch auch mit einem Link herstellen. Platzmangel habe ich nicht, wozu nun soll ich LVM einsetzen? Der zusammenhängen Festplattenplatz ist für mich kein Thema, Datensicherung auf externe Medien muss bei den Plattengrößen auch sein. Übersehe ich da etwas? Gruß Peter
Hallo, Am Sat, 03 Dec 2005, Peter Mc Donough schrieb: [..]
Platzmangel habe ich nicht, wozu nun soll ich LVM einsetzen? Der zusammenhängen Festplattenplatz ist für mich kein Thema, Datensicherung auf externe Medien muss bei den Plattengrößen auch sein. Übersehe ich da etwas?
IMHO noe. Ich mach das aehnlich. Du solltest nur aufpassen, wenn dir mal auf einer Partition der Platz ausgeht, dass du dann "sauber" arbeitest. -dnh -- "I picked up a Magic 8-Ball the other day and it said 'Outlook not so good.' I said, 'Sure, but Microsoft still ships it.'" - unk.
Hallo, On 03.12.2005 12:31, Peter Mc Donough wrote:
Hallo,
in der letzten ct (25/2005) wurde LVM besprochen. Eigentlich ganz interessant. ... Platzmangel habe ich nicht, wozu nun soll ich LVM einsetzen? Der zusammenhängen Festplattenplatz ist für mich kein Thema, Datensicherung auf externe Medien muss bei den Plattengrößen auch sein. Übersehe ich da etwas?
Nö. Du hast wohl nur gemerkt dass LVM für Dich nicht nötig ist. Ist ja kein Beinbruch :-) (Aber was nicht ist kann ja noch werden... ich habe schon öfters die Situation gehabt dass ich im Laufe der Levenszeit eines Rechners auf bestimmten Partitionen mehr Platz brauchte, aber eine längere Downtime nicht gern gesehen war. Dann ist es schön wenn man einfach eine weitere Platte dazubauen kann - mit einer Downtime von wenigen Minuten im günstigen Fall - und die dann im laufenden System erst partitioniert, als PV anmeldet, einer LV zuschlägt und dann die betreffende Partition vergrössert.) Arno
Gruß Peter
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Am Samstag, 3. Dezember 2005 12:31 schrieb Peter Mc Donough:
Hallo,
in der letzten ct (25/2005) wurde LVM besprochen. Eigentlich ganz interessant.
Aber, ich sitzte hier vor einen Einzelplatzrechner, mit zwei großen Festplatten (hat sich so ergeben), mit Windows XP und 64 und 32 bit Linux Varianten, die einfach in getrennten Partionen untergebracht sind. Die eigenen Daten sind, sofern sie nicht von einer bestimmten Linuxversion abhängig sind, auf einer große Datenpartition gelegt und von den "Linuxen", wo benötigt, verlinkt. Bei Wartung hänge ich die Datenpartiton aus. Sollte ich z.B. ein größers /tmp Verzeichnis brauchen, kann ich das doch auch mit einem Link herstellen.
Platzmangel habe ich nicht, wozu nun soll ich LVM einsetzen? Der zusammenhängen Festplattenplatz ist für mich kein Thema, Datensicherung auf externe Medien muss bei den Plattengrößen auch sein. Übersehe ich da etwas?
zwei Gründe: 1. Festplatten sind nur durch grössere oder mehr Festplatten zu ersezten -- und dann beginnt das Problem -- -- und mit LVM geht's etwas einfacher 2. snapshots: das Dateisystem für das Backup "einfrieren", damit das Backup auch konsistent ist. Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Dr. Jürgen Vollmer, Samstag, 3. Dezember 2005 21:20:
zwei Gründe: 1. Festplatten sind nur durch grössere oder mehr Festplatten zu ersezten -- und dann beginnt das Problem -- -- und mit LVM geht's etwas einfacher
Aber auch nur dann, wenn man ein Gehäuse mit vielen freien Schächten rumstehen hat. Aber das ist auch nicht das wahre, denn dann habe ich eine 40er Platte von ganz früher, dann kommt später eine 80er dazu, dann meinetwegen eine 120er und eine 160er. Per LVM kann ich über die ganzen schönen Platten ein logisches Volume legen. Aber was soll ich noch mit meiner alten 40er und der 80er im LVM-Verbund, wenn ich für fast kein Geld gleich eine 350er oder 400er Platte krieg, die dann auch noch neu ist und nicht schon tausende Betriebsstunden hinter sich hat, und die ganze Datenmenge auf einmal faßt? Meiner Meinung nach ist daher LVM nur dann sinnvoll, wenn ich mehr Kapazität brauche als die größten verfügbaren Platten bieten. Ansonsten bietet die Stückelei aus alten, nicht ganz so alten und noch weniger alten Platten keinerlei Vorteile. -- Andre Tann
Am Samstag, 3. Dezember 2005 22:06 schrieb Andre Tann:
Dr. Jürgen Vollmer, Samstag, 3. Dezember 2005 21:20:
zwei Gründe: 1. Festplatten sind nur durch grössere oder mehr Festplatten zu ersezten -- und dann beginnt das Problem -- -- und mit LVM geht's etwas einfacher
Aber auch nur dann, wenn man ein Gehäuse mit vielen freien Schächten rumstehen hat. Aber das ist auch nicht das wahre, denn dann habe ich eine 40er Platte von ganz früher, dann kommt später eine 80er dazu, dann meinetwegen eine 120er und eine 160er. Per LVM kann ich über die ganzen schönen Platten ein logisches Volume legen. Aber was soll ich noch mit meiner alten 40er und der 80er im LVM-Verbund, wenn ich für fast kein Geld gleich eine 350er oder 400er Platte krieg, die dann auch noch neu ist und nicht schon tausende Betriebsstunden hinter sich hat, und die ganze Datenmenge auf einmal faßt?
Meiner Meinung nach ist daher LVM nur dann sinnvoll, wenn ich mehr Kapazität brauche als die größten verfügbaren Platten bieten.
Ansonsten bietet die Stückelei aus alten, nicht ganz so alten und noch weniger alten Platten keinerlei Vorteile.
ausser man hat SCSI, hier gilt: mehr Platten = paralleler Zugriff = mehr Performance. Und warum sollte ich meine (teuren) SCSI-Platten 'rausschmeissen, nur weil ich mehr Patz brauche? (Hach und ich' geb's zu: meine Rechner-Anfänge stammen noch aus den Zeiten, da kostete eine 10MB-Platte (ja zehn-MEGA) noch ca. 2.000 DM (für einen Atari ST). Und in der Uni hatte die "dicke VAX" vielleicht gerade mal 100MB im _Schrank_ (und das für das ganze Institut). Diese Wurzeln kann ich nicht leugnen. Ich denke mir geht es da so, wie der Generation der Kriegskinder, sprich der Eltern meiner Generation, wenn sie sagen: Iss den Teller leer, man lässt nicht liegen ...) Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Dr. Jürgen Vollmer, Samstag, 3. Dezember 2005 22:38:
ausser man hat SCSI, hier gilt: mehr Platten = paralleler Zugriff = mehr Performance. Und warum sollte ich meine (teuren) SCSI-Platten 'rausschmeissen, nur weil ich mehr Patz brauche?
Auch SCSI-Platten machen irgendwann schlapp. Und ich tausche eine Platte lieber freiwillig als unfreiwillig, auch wenn die zu ersetzende Platte mal teuer war.
Und in der Uni hatte die "dicke VAX" vielleicht gerade mal 100MB im _Schrank_ (und das für das ganze Institut). Diese Wurzeln kann ich nicht leugnen. Ich denke mir geht es da so, wie der Generation der Kriegskinder, sprich der Eltern meiner Generation, wenn sie sagen: Iss den Teller leer, man lässt nicht liegen ...)
Das sind dann romantische Gründe, denen ich ihre Berechtigung durchaus nicht absprechen will. Eine gewisse Verwöhntheit liegt durchaus darin, eine noch funktionierende Platte außer Betrieb zu nehmen, nur weil es eine andere - größere - gibt. Aber rein kosten- und performance-mäßig scheint es mir eben manchmal sinnvoll zu sein, eine neue große Platte einzusetzen, anstatt mit alten und noch älteren Platten und LVM herumzustöpseln. -- Andre Tann
Am Samstag, 3. Dezember 2005 22:38 schrieb Dr. Jürgen Vollmer: [...]
ausser man hat SCSI, hier gilt: mehr Platten = paralleler Zugriff = mehr Performance.
Das hat ja wohl nichts mit der Plattenarchitektur, geschweige denn mit der Schnittstelle zu tun. Auch ATA/SATA-Platten kann man stripen.
Und warum sollte ich meine (teuren) SCSI-Platten 'rausschmeissen, nur weil ich mehr Patz brauche?
Vollkommen richtig. Sehe ich genauso
(Hach und ich' geb's zu: meine Rechner-Anfänge stammen noch aus den Zeiten, da kostete eine 10MB-Platte (ja zehn-MEGA) noch ca. 2.000 DM
Uh, in welcher Apotheke hast Du denn damals Deine Platten gekauft? ;)
(für einen Atari ST).
Hatte ich auch, und meine erste Festplatte dafür war eine Vortex im grauen, externen Gehäuse. Drinnen war eine lahme Seagate 5,25"/20MB MFM-Platte (ST-225) mit hurtigen 25 ms mittlerer Zugriffszeit an einem 8-Bit XT-Controller, der später in Eigeninitiative durch einen 8-Bit RLL-Controller ersetzt wurde. Und schwupps hatte man satte 30 MB. Die Vortex-Platte hat damals tatsächlich schlappe 2000 DM gekostet, aber für 20 MB.
Und in der Uni hatte die "dicke VAX" vielleicht gerade mal 100MB
... und kostete ein Vielfaches einer mickrigen Consumerplatte, während der zugehörige Streamer nur knapp 80 MB fasste und man das Band im Format einer Riesen-Torte nach knapp 80 MB 'schon' wechseln mußte.
im _Schrank_ (und das für das ganze Institut). Diese Wurzeln kann ich nicht leugnen. Ich denke mir geht es da so, wie der Generation der Kriegskinder, sprich der Eltern meiner Generation, wenn sie sagen: Iss den Teller leer, man lässt nicht liegen ...)
schwelg ;))) Gruß Martin
Hallo, Am Sat, 03 Dec 2005, Andre Tann schrieb:
Aber auch nur dann, wenn man ein Gehäuse mit vielen freien Schächten rumstehen hat. Aber das ist auch nicht das wahre, denn dann habe ich eine 40er Platte von ganz früher, dann kommt später eine 80er dazu, dann meinetwegen eine 120er und eine 160er. Per LVM kann ich über die ganzen schönen Platten ein logisches Volume legen. Aber was soll ich noch mit meiner alten 40er und der 80er im LVM-Verbund, wenn ich für fast kein Geld gleich eine 350er oder 400er Platte krieg, die dann auch noch neu ist und nicht schon tausende Betriebsstunden hinter sich hat, und die ganze Datenmenge auf einmal faßt?
Ack. Ich habe seit IIRC 5 Jahren immer 3 HDDs im Rechner und kaufe ungefaehr einmal im Jahr eine neue. Die alten werden dann leergeraeumt und ausrangiert.
Meiner Meinung nach ist daher LVM nur dann sinnvoll, wenn ich mehr Kapazität brauche als die größten verfügbaren Platten bieten.
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware. -dnh -- 144: Maxmimale Entfernung zweier Hubs 12800 km. (Roger Schwendker)
Meiner Meinung nach ist daher LVM nur dann sinnvoll, wenn ich mehr Kapazität brauche als die größten verfügbaren Platten bieten.
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Danke für die verschiedenen Meinungen. Mich überzeugt am meisten die Sache mit der zusätzlichen Schicht im System. Die Kostenfrage relativiert sich, wenn man den Ebay-Restwert der Platte herausfindet bzw. den Aufwand und den eventuellen Performanceverlust betrachtet, den eine "alte" Platte in das Multi-Gigaherzsystem bringt. Gruß Peter
David Haller wrote:
[...] Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Dann darfst Du aber wirklich nie auf eine neuere SuSE-Version umsteigen! ;-) Nur so als Beispiel: HAL steht fuer "Hardware Abstraction Layer" und ist auch so eine Art Zwischenschicht... CU, Th.
Hallo, Am Sun, 04 Dec 2005, Thomas Hertweck schrieb:
David Haller wrote:
[...] Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Dann darfst Du aber wirklich nie auf eine neuere SuSE-Version umsteigen! ;-) Nur so als Beispiel: HAL steht fuer "Hardware Abstraction Layer" und ist auch so eine Art Zwischenschicht...
Mir geht's eigentlich nur mit dem FS so. -dnh -- If you think sex is a pain in the arse, try a different position.
David Haller, Sonntag, 4. Dezember 2005 02:07:
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Was genau befürchtest Du denn? Ich hab den LVM testweise aus reiner Neugier auf einer Maschine am laufen. Sie steht ständig unter Last, läuft aber aus thermischen Gründen kaum je länger als zehn Stunden. Dann stürzt sie ab, kriegt einen Hard-Reset, und läuft weiter. Das geht nun schon seit einem Jahr so, und ich hab noch kein Problem am FS (xfs) oder am LVM festgestellt. -- Andre Tann
* Andre Tann wrote on Sun, Dec 04, 2005 at 22:33 +0100:
David Haller, Sonntag, 4. Dezember 2005 02:07:
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Was genau befürchtest Du denn?
Dann schreib ich auch mal was zu LVM :) Ist leider bisschen viel gelabere geworden (also nur bei Langweile lesen) - aber der Thread klingt ja nach "Erfahrungsaustausch". Ich hab recht früh mit LVM angefangen, weil ich das einfach toll fand. Flexibel und alles was man braucht. Als ich meinen privaten Server gebaut hab, waren die beiden IDE Platten noch nicht da (nach diveren Plattentoden mach ich alles ausser /tmp/ immer auf RAID1). Dann sollten noch zwei (alte) SCSI Platten für's Backup rein, hatte aber auch nur eine da. Also hab ich ein RAID1 mit einer Platte auf's SCSI gemacht, das als PV zum LVM geschoben und Linux installiert. Dann die zweite SCSI-Platte angehängt und RAID1 syncen lassen. Als die IDE Platten kamen, eingebaut, RAID1 drauf, PV ins LVM. Dann das SCSI-PV "rausgemovt". Auf das raid1 dann direkt Filesystem drauf (also kein LVM), damit ich notfalls mit einem linux 2.0.34 mein Backup als ext2 mounten kann :) Dann hab ich divere resizes gemacht. Testweise hatte ich auf meiner (sehr ähnlich, bloss ohne SCSI) konfiguierten Workstation erstmal ganz knappe /usr und /var gemacht, die ich öfter mal vergrössern musste (zum Üben). Mein /tmp ist auf einem RAID0-LVM (damit schön dynamisch) und hübsch schnell (101.59 MB/sec mit billigen Standard-IDE Platten). Snaps waren prima für Backups. Hatte mal so eine Bastelei angefangen, wo diverse Dienste runtergefahren wurden, snap gezogen und die Dienste gleich wieder gestartet wurden. Dann wurde der snap in aller Ruhe auf's Band geschrieben. Das mit den Diensten haben wir dann aber wieder ausgebaut (waren etliche Problemchens, eines z.B. das openldap öfter mal nicht starten wollte und dann die Mails nicht ausgeliefert wurden und die SMSs genervt haben, vom "ssh $host rcldap restart" ganz zu schweigen). Die rcscripte waren einfach nicht gut genug. Ähnliche Probleme auch mit PostgreSQL (das beliebte /tmp/socket Problem und so). Aber schon allein /home/ zu sichern, ohne das ein "halbes FTP Userupdate" drauf war, war schon fein :) Überhaupt: alles war fein. (Betonung liegt auf "war"). Jetzt zurück zu meiner privaten Workstation. Da hab ich das Board aufgerüstet. Windows (ist auch mit auf der Büchse) lief danach problemlos weiter. Linux nicht, der Chipsatz wurde nicht erkannt und meine HDDs liefen ohne DMA mit 3 MB/sec :( Ich wollte einen 2.6er Kernel in meine (mit apt schon recht weitläufig geupdatete) "ehemalige" SuSE 8.2 installieren. Nach ca. drei Tagen aufgegeben (initrd mochte nicht starten). OpenSuSE 10 gesaugt, yast update gemacht ... und initrd mochte nicht starten (siehe auch meine anderen Postings ;-)). Ich kämpfe also jetzt noch. Hätte ich kein LVM gehabt, und den Kram einfach auf ne USB Platte kopiert, hätte ich viel Zeit gespart, selbst wenn ich dabei zugeguckt hätte. Macht man bei Windows ja auch so. grpmf. Meiner Meinung nach nützt einem das schönste Kernelfeature nichts, wenn die Distros lieblose Skripte und yet-another-misconfiguration-tool mitbringen, die nicht sauber funktionieren, Seiteneffekte haben, Fehlermeldungen verschlucken und den Admin einschränken. Ich persönlich hab bisher fast immer Backups gebraucht, weil irgendwas im Userland Mist gemacht hat (so ein Yast, Office oder sonstwas). Na gut, paar Probleme mit reiserfs hatte ich natürlich auch (mit SuSE 7.1 z.B.), aber reiserfs soll man ja auch nicht nehmen (damals war ext3 leider noch nicht "freigegeben") :) Zusätzliche Schichten können auch helfen (RAID1 z.B.). Inzwischen hab ich aber weniger Angst vor Bugs im LVM des Kernels als vor der nächsten Macke im Yast oder weiss ich was. Allerdings hab ich auch (meistens ;)) brauchbare Backups zur Hand. Und zwar auf meinen SCSI-Platten, eine Kopie dieser Kopie auf meiner Workstation in /tmp/ von wo ich auf DVD-RAM synchronisiere... Man kann ja nicht paranoid genug sein. Heute würde ich LVM bei SuSE nicht mehr "bloss so" installieren, weil ich Angst vor dem nächsten Update hätte (und nicht vor Bugs im Kernellayer)! Ach so, mein SuSE 10 lief nicht mit meinem alten Kernel 2.4.20-4GB-athlon: initrd natürlich, LVM Tools waren wohl NICHT abwärtskompatibel ("vgscan: LVM1 kernel but no /sbin/vgscan.old" ist doch ein Witz!) - na ja, hab ich nicht weiter verfolgt, man würde ich hinskripten können, wenn man ne Woche Zeit hat. Jaja, liebes LVM. Man muss dabei bedenken, dass SuSE LVM seit ich glaube 6.4 unterstützt und damals glaub ich die erste Distribution war. Mit 8.2 gings bei mir richtig gut - dachte, jetzt wird diese Technologie beherrscht - aber OpenSuSE 10 belehrte mich eines anderen. Ach so, und ich glaube nicht unbedingt, dass andere Distributionen "besser" sind! Es ist halt einfach komplex und es darf nichts kosten. Das LVM selbst hat aber alles überlebt, sämtlichen komischen Yast und initrd Aktionen, falsche LVM-Tool-Versionen (die nicht zum Kernel passten) usw! Vor einem Jahr oder so hatte ich meinen Server von SuSE 7.3 auf 8.2 geupdatet. 8.2 lief ein Jahr gut auf meiner WS und hatte sich damit "qualifiziert". Ich hab einen neuen Server gebaut, weil ich wusste, dass meine ganzen Spezialsachen Zeit brauchen (daher auch keine LVM-Update-Tests :)). Die liefen ne Weile parallel und der neue hat nach und nach die Funktionen des alten übernommen. Irgendwann hab ich den alten ausgeschaltet (jetzt könnte ich ihn langsam mal wegschmeissen, aber ich bin so sentimental :-)). Aus der "LVM-Wolke" (Updateprobleme) fiel ich erste letzte Woche beim Update-Versuch meiner Workstation :) Daher lieber alles vermeiden, was geht, weil man damit statistisch auch Probleme vermeidet. Also halt wenig Features nutzen etc. Wer keine TV Karte hat, hat auch keine Probleme damit :) Bloss blöd, wenn ein Kumpel mit einer USB Platte kommt und man mit einem 2.2er Kernel dasteht :-) Na gut, ich wünsch euch noch eine schöne Woche!! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Sun, 04 Dec 2005, Steffen Dettmer schrieb: [..bigsnip..]
Daher lieber alles vermeiden, was geht, weil man damit statistisch auch Probleme vermeidet. Also halt wenig Features nutzen etc. Wer keine TV Karte hat, hat auch keine Probleme damit :) Bloss blöd, wenn ein Kumpel mit einer USB Platte kommt und man mit einem 2.2er Kernel dasteht :-)
*g* Hm. Ich glaube, deine Mail ist ein Paradebeispiel: einerseits hattest du Vorteile durch LVM (?), andererseits aber auch wieder Aerger... Ich hoffe, du hattest keinen Datenverlust (wobei, da zaehl ich alles dazu, was man aus nem Backup wiederherstellen muss). Siehe meine andere Mail: man sollte wissen warum und wozu man LVM und/oder RAID verwendet... -dnh --
Was ist "draußen"? Der grosse blaue Raum. U.a. daran zu erkennen, dass die Decke sehr hoch ist und an selbiger tagsueber eine nahe offen brennende Kernfusion als Deckenlampe dient waehrend nachts eine dunkle Deckenfarbe mit vielen kleinen hellen Punkte sowie manchmal einer blassen Lampe verwendet wird. -- Alexander Schreiber
On Sunday 04 December 2005 23:41, Steffen Dettmer wrote:
* Andre Tann wrote on Sun, Dec 04, 2005 at 22:33 +0100:
David Haller, Sonntag, 4. Dezember 2005 02:07:
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Was genau befürchtest Du denn?
Dann schreib ich auch mal was zu LVM :) Ist leider bisschen viel gelabere geworden (also nur bei Langweile lesen) - aber der Thread klingt ja nach "Erfahrungsaustausch".
[...]
Jetzt zurück zu meiner privaten Workstation. Da hab ich das Board aufgerüstet. Windows (ist auch mit auf der Büchse) lief danach problemlos weiter. Linux nicht, der Chipsatz wurde nicht erkannt und meine HDDs liefen ohne DMA mit 3 MB/sec :( Ich wollte einen 2.6er Kernel in meine (mit apt schon recht weitläufig geupdatete) "ehemalige" SuSE 8.2 installieren. Nach ca. drei Tagen aufgegeben (initrd mochte nicht starten). OpenSuSE 10 gesaugt, yast update gemacht ... und initrd mochte nicht starten (siehe auch meine anderen Postings ;-)).
Ich kämpfe also jetzt noch.
Hätte ich kein LVM gehabt, und den Kram einfach auf ne USB Platte kopiert, hätte ich viel Zeit gespart, selbst wenn ich dabei zugeguckt hätte. Macht man bei Windows ja auch so. grpmf.
Warum kopierst Du den Kram nicht trotz LVM auf die USB Platte? Zugegeben ist es nicht mit einem Befehl getan von einem Rettungssystem an die Daten zu kommen, aber eigentlich ohne Probleme zu machen. Und am Ende steht wieder ein ganz normales "mount ...". Du musst vorher nur pvscan, vgscan etc. laufen lassen. Und ein vgchange musste glaub ich auch noch gemacht werden. Aber Anleitungen hierzu findet man im Inet zuhauf. Viele Grüße Thomas
* Thomas Vollmer wrote on Mon, Dec 05, 2005 at 09:47 +0100: [...]
Hätte ich kein LVM gehabt, und den Kram einfach auf ne USB Platte kopiert, hätte ich viel Zeit gespart, selbst wenn ich dabei zugeguckt hätte. Macht man bei Windows ja auch so. grpmf.
Warum kopierst Du den Kram nicht trotz LVM auf die USB Platte?
:-) Weiss nicht, vielleicht Sportsgeist weil ich es jetzt ja doch hinbekommen hab. Ausserdem müsste ich ja sonst zugeben, dass ich mit dem Setzen auf LVM einen Fehler gemacht hab :-)
Zugegeben ist es nicht mit einem Befehl getan von einem Rettungssystem an die Daten zu kommen,
Nee? Na egal.
Du musst vorher nur pvscan, vgscan etc. laufen lassen. Und ein vgchange musste glaub ich auch noch gemacht werden.
Ja, um lvm zu aktivieren macht man sowas wie: $ modprobe dm_mod $ vgscan $ vgchange -a y Wobei ersteres bei SuSE 10 nicht notwendig ist, weil schon erledigt. Natürlich können divere Configfile einem noch Steine in den Weg legen :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Tue, 06 Dec 2005, Steffen Dettmer schrieb:
$ modprobe dm_mod $ vgscan $ vgchange -a y
Wobei ersteres bei SuSE 10 nicht notwendig ist, weil schon erledigt.
Aeh, ist da nicht ein passender Eintrag in /etc/modules.conf | /etc/modprobe.conf | /etc/modprobe.d/device_mapper [1] sinnvoller? Nurmal so nebenbei. -dnh, der modprobe weder als root noch als user noch in irgendeinem boot-script haendisch verwendet. Aeh, halt, doch, fuer iptables lade und entlade ich die Module im (handgekloeppelten) init-script. Alles andere laeuft sauber und automatisch ganz ohne explizites "modprobe" oder gar "insmod" irgendwo in einem script, sondern nur ueber passende aliase bzw. Abhaengigkeiten in meiner /etc/modules.conf. [1] anzulegen, analog zu "sound" o.ae. ebenda --
Naja spiele ich halt wieder Frisbee mit der NT CD. Funktioniert nicht. Stürzt immer ab. -- Hans Pueschel in dasr
Hallo, Am Sun, 04 Dec 2005, Andre Tann schrieb:
David Haller, Sonntag, 4. Dezember 2005 02:07:
Nun, die "snapshot"-Funktion wuerde mich reizen, aber ich misstraue einer zusaetzlichen Schicht zwischen FS und Hardware.
Was genau befürchtest Du denn? Ich hab den LVM testweise aus reiner Neugier auf einer Maschine am laufen. Sie steht ständig unter Last, läuft aber aus thermischen Gründen kaum je länger als zehn Stunden. Dann stürzt sie ab, kriegt einen Hard-Reset, und läuft weiter. Das geht nun schon seit einem Jahr so, und ich hab noch kein Problem am FS (xfs) oder am LVM festgestellt.
Hm. Haette ich das "ich" noch hervorheben muessen? ;) Fuer mich gilt jedenfalls folgendes: * ich bin mit Partitionstabellen auf "du", mir reicht da 'debug.com' von DOS oder 'dd' + 'hexdump\|od\|...' und bc oder ein Taschenrechner um die zu lesen und die Tabellen der erw. und log. Partitionen auszulesen usw... * ich verstehe ext2/3 fs (reiserfs setze ich nicht mehr ein). Und mir reicht $bootcd mit debugfs um ggfs. am FS rumzureparieren (z.B. Knoppix). Und zur Not wohl auch wieder 'dd' + 'hexdump'... * Ich wil keine weitere Abstraktionsebene dazwischen. Und weil LVM AFAIK seine Verwaltung eher "willkuerlich" auf den Partitionen verteilt ist ein "haendisches" "entlanghangeln" noch nerviger als bei logischen Partitionen... Auch Software-RAID mag ich aus dem gleiche Grunde nicht (und ich brauch's einfach nicht). Bei HW-RAID ist ja sowieso auf Gedeih und Verderb den (proprietaeren) (oft closed-source) Treibern ausgeliefert... Ja, das ist _mein_ Spezialfall, der sicher nicht verallgemeinbar ist, aber dennoch Hinweise gibt: <IMHO> * HW-RAID sollte man generell eher vermeiden (da meist closed-source bzw. sowieso an einen bestimmten Controller gebunden). Einfach die RAID-Platten von Controller_A auf Controller_B umstoepseln ist AFAIK umoeglich, sofern nicht beide Controller sowohl von der HW _als auch_ von der Firmware identisch sind. (Laeuft da nicht grad ne Fragen ueber die Liste, wo nach Tausch des Controllers nix mehr geht?) Gibt es Open-Source-Treiber fuer Linux u.a. OSen (wie AFAIK von 3ware) kann man es evtl. verwenden, wenn man es braucht _und_ weiss warum und wie -- da kann man ggfs. noch (wenn man sich _sehr gut_ auskennt und den Treiber quasi "zerlegt") Hand anlegen und nachvollziehen, wie der Treiber arbeitet und die Daten auf der Platte verteilt... Das ist aber ein riesen Aufwand... Dagegen ist Partitionstabellen lesen ein Zuckerschlecken, vermute ich mal... Also: lieber Haende weg... Und wenn (s.u.), dann bitte mit Open-Source-Treiber! * Fuer SW-RAID und LVM gilt das gleiche, nur mehr auf SW-Ebene: es wird eine (oder wenn man beides verwendet: zwei) zusaetzliche Ebene(n) zwischen FS und HW "eingezogen". Die zusaetzliche Kompexitaet birgt Risiken. z.B. bzgl. dem Verhalten bei: - Fehlern auf HW-Ebene (z.B. Sektorverluste, Controller defekt) - Fehlern auf Logik-Ebene (RAID) - Fehlern auf Logik-Ebene (LVM) Verwendet man weder Software-RAID noch LVM fallen 2 von 3 Ebenen weg, auf denen Fehler "unterhalb" des FS auftreten koennen. Bzgl. HW-RAID s.o. </IMHO> Wie wir alle wissen (sollten) ist Software grundsaetzlich fehlerhaft! Also auch die Festplatten-Treiber, das Software-RAID und LVM, als auch die diversen Dateisysteme (und die Firmware von HW-RAID-Controllern). Und ich finde, man sollte nicht mehr (per Definition) fehlerhafte Software fuer den Festplattenzugriff verwenden als _noetig_. Und wenn man SW-RAID/LVM verwendet sollte man _stabile_ Versionen verwenden, wenn man nicht gerade eben die neuen Versionen austesteten will. Fazit: wenn man nicht _genau_ sagen kann, _warum_ man RAID oder LVM braucht / will, dann sollte man es nicht verwenden. Und wenn man es verwendet, sollte man sich der Risiken bewusst sein. BTW: ich will hier nicht SW-RAID und/oder LVM schlechtmachen, im Gegenteil. Es gibt viele Gruende, warum man das SW-RAID (md (bis Kernel-2.4) oder auch dm (device-mapper, ab Kernel 2.6.x)) verwenden will oder gar sollte, auch fuer LVM gibt es viele Gruende. ABER: Wie geschrieben, die "snapshot"-Moeglichkeit von LVM finde ich gut, nur ueberwiegen _fuer mich_ die Nachteile, die ich fuer dieses eine Feature, das _ich_ "brauchen koennte", in Kauf nehmen muesste. Fuer _mich_, und IMHO auch fuer viele, die nicht weiter darueber nachdenken, sind RAID und LVM nicht sinnvoll. Wenn man das Linux SW-RAID (md/dm) oder LVM 1/2 einsetzen will, sollte man sich voher genau ueberlegen _warum_ und welche Risiken man damit eingeht. Und eben Nutzen und Risiken abwaegen. Leider wird hier oft nicht genug auf die Risiken hingewiesen... Ich fasse nochmal zusammen, wie auf Dateien zugegriffen werden kann: "LinuxVFS" stehe hier stellvertretend fuer die "syscalls" 'open(2)/read(2)/write(2)'. In der Praxis gibt's noch diverse Ebenen "darueber" via libc / perlIO / Gtk / QT, vgl. 'printf(3)' vs. 'write(2)'. Diese syscalls werden wiederum auf die Funktionen des VFS umgesetzt (vgl. read auf /dev/bla, /home/bla und /proc/bla). Also beschaeftigen wir und mal nur mit der Stufe ab dem VFS. Definitionen: FS-Treiber := Treiber fuer "echte" Dateisysteme wie ext2 / ext3 / reiserfs / xfs / jfs / vfat / ... (zusaetzliche Ebenen fuer emulierte Dateisysteme wie smbfs / lufs / ... lass ich mal weg) HW-Treiber := Treiber fuer ein Speichermedium via IDE/SCSI, bspw.: IDE, usb-storage (via scsi), SATA (via IDE/SCSI?), SCSI, ... Mit o.g. Definitionen gilt also "normal": LinuxVFS -> FS-Treiber -> HW-Treiber -> HW und mit LVM: LinuxVFS -> FS-Treiber -> LVM -> HW-Treiber -> HW mit (Linux Software) RAID: LinuxVFS -> FS-Treiber -> RAID -> HW-Treiber -> HW mit LVM + RAID: LinuxVFS -> FS-Treiber -> LVM -> RAID -> HW-Treiber -> HW Und die "LinuxVFS" Ebene ist schon die der "syscalls" (read(2), write(2) etc.), d.h. eine "Ebene", die man selbst als Programmierer eher selten verwendet... _ICH_ kann jedenfalls sowohl auf LVM als auch auf RAID verzichten, zumal sowohl LVM als auch RAID durchaus komplex sind. Das ganze ist eine Komplexitaet, deren Vorteile ich kenne, die ich aber nicht benoetige. Und somit weglasse. LVM/RAID zu verwenden, nur weil es "cool" oder "bequem" ist, ist IMHO fahrlaessig. Man sollte wissen, was man tut, und v.a. wissen warum. Hm. Kann jemand Teile dieser Mail zumindest ansatzweise zu ner Antwort einer "FAQ" umformulieren und an 'suse-linux-faq@lists.koehntopp.de' mailen? ;) Ich hab erstmal keinen Kopp dafuer... Halt, doch, Rubrik / Frage geht noch: "Ist LVM / Software-RAID fuer mich sinnvoll?" (ja, ist schwierig ;) -dnh -- Och yes. I used to have a brain once. If anyone sees it, please ask it to come back, I miss it sometimes. -- Frossie
* David Haller wrote on Mon, Dec 05, 2005 at 05:36 +0100: [...debugfs...] Ja, das kann ich dann gut verstehen, wenn man noch /begreifen/ will, was genau passiert, dann was einfaches und bewährtes! Was genau ein LVM2 heute macht, ist sicherlich ne Diplomarbeit wert - Partionstabellen kann man sicherlich an einem Tag verstehen.
Auch Software-RAID mag ich aus dem gleiche Grunde nicht (und ich brauch's einfach nicht).
Bei RAID-1 (mirror) gilt das wohl nicht so ganz, weil der "Inhalt" der Partionen ja "gleich" ist, sprich, man kann ein RAID-1 device auch "einzeln" mounten - oder debugfs'en. Muss dann bloss aufpassen, welche Partition man neu ins RAID-Set nimmt. Für mich ist das hier schon wieder der Punkt, wo mein Verständnis aufhört; wenn ich zwei devices eines Raidsets unterschiedlich per Hand "manipuliere" (z.B. einfach mal mounte), was macht das raid dann genau oder merkt's dass am Ende gar nicht? :)
Bei HW-RAID ist ja sowieso auf Gedeih und Verderb den (proprietaeren) (oft closed-source) Treibern ausgeliefert...
Für mich hat ein HW-Raid einen SCSI-Anschluss und überhaupt keinen Treiber, sonst ist's IMHO nur HW/Halbe oder auch Raid 1/2 :-)
* HW-RAID sollte man generell eher vermeiden (da meist closed-source bzw. sowieso an einen bestimmten Controller gebunden). Einfach die RAID-Platten von Controller_A auf Controller_B umstoepseln ist AFAIK umoeglich, sofern nicht beide Controller sowohl von der HW _als auch_ von der Firmware identisch sind.
Ja, ist prima, wenn man ein HW Raid "günstig" gekauft hat, und dann nach drei Jahren keine Ersatzteile (sprich neue Kontroller) mehr bekommt :) Und wenn man ein Problem hat, ist man gleich ganz am Ende (wobei Leute wie Du im hexeditorpartionsmodus sonst evtl. noch Chancen hätten)...
Also auch die Festplatten-Treiber, das Software-RAID und LVM, als auch die diversen Dateisysteme (und die Firmware von HW-RAID-Controllern).
Genau, und das beste RAID-LVM-Sonstwas ersetzt nicht das klassische Backup auf Medien, die räumlich getrennt gelagert werden (kann ja auch mal brennen) :)
Fazit: wenn man nicht _genau_ sagen kann, _warum_ man RAID oder LVM braucht / will, dann sollte man es nicht verwenden. Und wenn man es verwendet, sollte man sich der Risiken bewusst sein.
Seh ich ähnlich, allerdings hatte ich persönlich mit RAID noch keine schlechten Erfahrungen, dafür schon viel Arbeit nach Plattentot gespart. Hat mir jedenfalls gefallen, Dein Posting, danke. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Tue, 06 Dec 2005, Steffen Dettmer schrieb:
* David Haller wrote on Mon, Dec 05, 2005 at 05:36 +0100: [...debugfs...]
Ja, das kann ich dann gut verstehen, wenn man noch /begreifen/ will, was genau passiert, dann was einfaches und bewährtes! Was genau ein LVM2 heute macht, ist sicherlich ne Diplomarbeit wert -
ACK.
Partionstabellen kann man sicherlich an einem Tag verstehen.
NACK. Zumindest nicht auf der Ebene wo man mit debug.com oder dd + hexeditor hantiert. Ich habe damals den Artikel in der c't Mai/97 gelesen. Und eigentlich nix verstanden. IIRC hat mir dann aber ungefaehr ein Jahr spaeter beim rumpartitionieren mit Partition Magic unter Win95 und bei einem nicht "deaktivierten" Vamos als Bootmanager IIRC Partition Magic die Partitionstabelle eines logischen LWs komplett mit 0xF6 ueberschrieben (was ich aber erst spaeter, s.u. diagnostizieren konnte). Also, ich, nicht faul, c't Mai/97 rausgekramt und nochmal gruendlich gelesen. Und dann mit debug.com den MBR ausgelesen (der war i.O.). Also, weitergehangelt zum "EPBR" der erw. Partition. usw... Auslesen, umrechnen, BR neuschreiben... Letztlich konnte ich aus den redundanten Informationen in den FAT32 Bootrecords bzgl. FS-Anfang und Laenge alles wieder herstellen, habe den Anschluss zur naechsten logischen Partition gefunden usw. und die so reparierte Partitionierung hat funktioniert (IIRC sogar mit Umpartitionierungen) bis die Festplatte in Rente ging... Der Folgeartikel in der c't 06/00 war teilweise besser, teilweise schlechter, fuer mich aber sowieso zwei Jahre zu spaet ;) BTW: ich vermisse bei ext2/ext3 solch redundante Informationen ueber das FS im Superblock. Aber immerhin ist der SB selber wesentlich robuster abgespeichert als bei FAT* und NTFS. Hm. Vielleicht sollte ich mich doch mal gruendlicher damit beschaeftigen und evtl. darauf hinarbeiten, dass sowas im ext2/3 SB mit abgelegt wird. Platz genug sollte es im SB noch geben, denn 2*48 Bit sollten sich da finden (fuer ATA mit 48bit Sektor-Offsets/Laengen -> siehe sig). /tmp/test8 $ cat ext3-2.6.x.c #include "/SUSE91/usr/src/linux-2.6.4-52/include/linux/ext3_fs_sb.h" int main(void) { printf("%i\n", sizeof(struct ext3_sb_info)); }; /tmp/test8 $ gcc -nostdinc -I /SUSE91/usr/src/linux-2.6.4-52/include -D__KERNEL__ -DARCH_FLAVOR_I386_DEFAULT -I /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/include/ -o ext3-2.6.x ext3-2.6.x.c /tmp/test8 $ ./ext3-2.6.x 200 D.h. es werden bisher 200 von max. 512 Bytes fuer den ext3-Superblock (definiert in ext3_fs_sb.h) verwendet. (wenn ich mich nicht taeusche -- wie gesagt, ich muesste mich genauer einlesen).
Auch Software-RAID mag ich aus dem gleiche Grunde nicht (und ich brauch's einfach nicht).
Bei RAID-1 (mirror) gilt das wohl nicht so ganz, weil der "Inhalt" der Partionen ja "gleich" ist, sprich, man kann ein RAID-1 device auch "einzeln" mounten - oder debugfs'en. Muss dann bloss aufpassen, welche Partition man neu ins RAID-Set nimmt.
Kann man? Schon mal angeschaut/ausprobiert? Mit dd / vche? Ich habe hier kein RAID, koennte mir aber vorstellen, dass da noch irgendwelche Metainformationen irgendwo mit auf Platte landen (muessen), das RAID muss den Krempel doch auch irgendwie erkennen bzw. dessen Zustand (syncronisiert oder nicht etc.)... Und schon muss man sich durch die RAID Quelltexte wuehlen... Aber: wie gesagt: ich weiss nicht, wie das SW-RAID (md/dm) bei Linux im Detail funktioniert, ich habe eben keinen Bedarf.
Für mich ist das hier schon wieder der Punkt, wo mein Verständnis aufhört; wenn ich zwei devices eines Raidsets unterschiedlich per Hand "manipuliere" (z.B. einfach mal mounte), was macht das raid dann genau oder merkt's dass am Ende gar nicht? :)
s.o. Ich *vermute*, dass dass "ganz so einfach" ohne das RAID-Layer nicht geht... D.h. "einfach als $fs mounten" oder "debuggen" ist nicht.
Bei HW-RAID ist ja sowieso auf Gedeih und Verderb den (proprietaeren) (oft closed-source) Treibern ausgeliefert...
Für mich hat ein HW-Raid einen SCSI-Anschluss und überhaupt keinen Treiber, sonst ist's IMHO nur HW/Halbe oder auch Raid 1/2 :-)
*hehe*
* HW-RAID sollte man generell eher vermeiden (da meist closed-source bzw. sowieso an einen bestimmten Controller gebunden). Einfach die RAID-Platten von Controller_A auf Controller_B umstoepseln ist AFAIK umoeglich, sofern nicht beide Controller sowohl von der HW _als auch_ von der Firmware identisch sind.
Ja, ist prima, wenn man ein HW Raid "günstig" gekauft hat, und dann nach drei Jahren keine Ersatzteile (sprich neue Kontroller) mehr bekommt :)
ACK.
Und wenn man ein Problem hat, ist man gleich ganz am Ende (wobei Leute wie Du im hexeditorpartionsmodus sonst evtl. noch Chancen hätten)...
Nur _EXTREM_ muehsam. Also eigentlich nur die Profis von $Datenrettungsfirma... Denn einzelne Dateifragmente aus $beliebigen Sektoren zusammenpfriemeln lohnt nicht wirklich, wenn man dafuer keine SW hat. Und die gibt's nicht frei. Hoechstens eben bei $Firma. Ja, ich koennte sicherlich z.B. jew. den ersten Sektor eines JPEG finden, indem ich nach dem String "JFIF" an einer passenden Stelle suche, aber finde du mal JPEGs, die komplett in einem Sektor, oder auch FS Block (MS: Cluster) liegen (also <= 512 Byte bzw. 4096 Byte sind)... Die Folgesektoren (-bloecke, -cluster) der Datei zu finden ist ohne FS-Strukturen eine Sysiphus-Arbeit und haendisch praktisch unmoeglich. Und wenn ich schon sehe, dass meine _plain-text_ E-Mails die 512 Byte praktisch immer, und die 4KB sehr haeufig ueberschreiten... (mal ganz davon abgesehen, dass ich das mbox-Format verwende ;)
Also auch die Festplatten-Treiber, das Software-RAID und LVM, als auch die diversen Dateisysteme (und die Firmware von HW-RAID-Controllern).
Genau, und das beste RAID-LVM-Sonstwas ersetzt nicht das klassische Backup auf Medien, die räumlich getrennt gelagert werden (kann ja auch mal brennen) :)
ACK.
Fazit: wenn man nicht _genau_ sagen kann, _warum_ man RAID oder LVM braucht / will, dann sollte man es nicht verwenden. Und wenn man es verwendet, sollte man sich der Risiken bewusst sein.
Seh ich ähnlich, allerdings hatte ich persönlich mit RAID noch keine schlechten Erfahrungen, dafür schon viel Arbeit nach Plattentot gespart.
Ich vermute aber mal stark, dass du dir vorher Gedanken darueber gemacht hast, warum du RAID verwenden willst -- und welchen "RAID Level", also z.B. ob 0, 1, 5, 10... Und das tut Otto-Normal-Yast-Nutzer tendenziell aber nicht. Von Benutzern anderer !Unix OSen sowie den OS Xern ganz zu schweigen... Ist IMO ein bisserl wie mit den "Personal Firewalls", vgl. de.comp.security.firewalls ;)
Hat mir jedenfalls gefallen, Dein Posting, danke.
*g* Danke! -dnh -- Naja, zumindest war Maxtor "weitsichtig": mit einer 48bit-Adressierung kann man 134217728 GB (128 Petabyte) ansprechen, das sollte eigentlich fuer ein paar Jaehrchen reichen, oder? ;)) [David Haller in suse-linux]
participants (9)
-
Andre Tann -
Arno Lehmann -
David Haller -
Dr. Jürgen Vollmer -
Martin Falley -
Peter Mc Donough -
Steffen Dettmer -
Thomas Hertweck -
Thomas Vollmer