Mailinglist Archive: opensuse-de (1951 mails)
| < Previous | Next > |
Re: wozu LVM logical volume manager
- From: David Haller <david@xxxxxxxxxx>
- Date: Mon, 5 Dec 2005 05:36:34 +0100
- Message-id: <20051205043634.GA30940@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxx'
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
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@xxxxxxxxxxxxxxxxxx'
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
| < Previous | Next > |