Zugschlusbeobachtungen (Entries tagged as lvm)

Unified Kernel for etch, lenny and sid

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 06 Aug 2009 10:44:00 +0200

Traditionally, the Linux kernel is software that I compile myself from pristine upstream sources for various reasons. I have three major kernel flavours that get built (server, desktop and notebook), and I am pretty current in running a bleeding edge kernel. This is not really necessary any more nowadays, but it’s a tradition that works pretty well.

My kernels get built on sid and are packaged up with kernel-package, and equivs builds a dependency helper package which pulls in the kernel’s dependencies such as initramfs-tools and takes care of cross-version updates like going from 2.6.29 to 2.6.30. Up to now, I was always able to run a kernel built this way on all my systems which can range from oldstable to unstable.

This has recently become a bit harder when unstable’s udev started to complain that the sysfs layout was deprecated and that I should unset CONFIG_DEPRECATED_SYSFS in my kernel configuration or lose some of udev’s functionality, since a kernel compiled without CONFIG_DEPRECATED_SYSFS doesn’t properly boot on etch.

Since I wanted to avoid building even more kernel flavours, I decided to investigate which package I need to backport to etch to get kernels without CONFIG_DEPRECATED_SYSFS to work on etch. To my surprise, the cause for not booting on etch was not udev, but lvm2. With lvm2 2.02.39 (and the corresponding libdevmapper, 1.02.27-4) ported back from lenny to etch, my etch systems boot fine with CONFIG_DEPRECATED_SYSFS unset. udev can happily stay at etch’s version, 0.105-4etch1.

From etch to lenny to squeeze, the lvm2 package has evolved quite a bit. Since there is only one LVM flavour left, the lvm-common package vanished in the transition from etch to lenny, and libdevmapper still has its own source package in lenny, but is built from lvm2’s source package itself in squeeze. So, as a heads-up, there needs to be special handling for lvm-common when installing the backport on etch.

I decided to backport lvm2 from lenny to etch to allow this particular derivation from the distributions’s versions to vanish in reasonably short time when my last etch boxes get finally updated to lenny. And my dependency helper has been extended to now pull in the backported version of lvm2 to avoid nasty reboot surprises.

partition table gone, data still present

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 08 Apr 2009 22:58:32 +0200

I just wanted to make an USB stick bootable and wondered why mkdiskimage -4 /dev/sda 0 32 64 complained about the disk having too many cylinders. After a few moments, it ocurred to me that since libata, the system hard disk has become sda and that the stick was sdb or sdc. One ctrl-C later, fdisk confirmed both counts: That I accidentally started mkdiskimaging my main system hard disk and that the partition table was already gone.

A few hours later, the notebook is back in business without too much data loss. Lucky me.

My notebook has an “alibi” installation of Windows XP in its first primary partition sized 4 GB. Since I aborted the mkdiskimage process early enough, I hoped that only the windows installation was hosed. The Linux system is entirely in LVM (with crypted LVs), and LVM hadn’t noticed yet that its PV was gone. I reckoned that I still had a chance to rescue my data if I didn’t reboot.

So I hastily commandeered an USB hard disk (thanks, $CUSTOMER, for quickly supplying one), fdisked, pvcreated and vgextended it and started the pvmove. While this was happening, I theoretically was able to continue working, which I didn’t because I was afraid of losing. About half an hour into the copy process, the USB disk chose to deregister itself and the pvmove aborted. Rebooting the disk made it reappear as sde (it was sdd before), and miraculously, a new pvmove call just worked. However, a good fraction of actions on the shell resulted in a lot of input/output errors on the screen. I guessed that this was the first sign of my data finally dying, but I let the pvmove continue.

After the pvmove was finished (which was rather fast since the move of the “crypted LV” means that the crypted data is moved and not de- and recrypted), I had to recreate a /dev/sda2 partition with type 8e before the LVM tools allowed me to vgreduce the VG.

I then zeroed out the first 10 GB of the internal disk and spent a few hours reinstalling and patching XP from scratch before I finally went through the pvcreate, vgextend, pvmove routine in the other direction. Then the big moment arrived: fsck of all LVs.

I guess that the reason for the input/output errors was that /usr was completely hosed (no single file outside lost+found), but /home and all other file systems holding data where the way back to the (a week old) backup would have been quite painful were ok. I pulled /, /usr and /var from the backup to be consistent again, updated to current sid (avoiding KDE 4 for the time being) and could start working again.

The only real loss was a few hours of work that were stored in /usr/local which died along with /usr, so the result of my stupidity was not very catastrophic but still a good lesson. And I have learned that LVM is a robust and resilient beast. Good work. Now I’d like to know what happened to my /usr - I always had the impression that pvmove should not break data even when the target disk suddenly goes away...

LV naming, UUIDs, file systems labels

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 02 Apr 2009 11:04:12 +0200

In the last few weeks, I spent quite some time wondering about how to arrange the hard disk layout of my productive systems in the future. This article outlines my thoughts and would like to ask the lazyweb for comments.

I try to keep my Debian servers as identically as possible, making it possible to talk non-linux persons remotely through the system without having to worry about this particular box’ configuration.

I have been especially worrying about:

(h1) root FS location (/etc/fstab, grub/menu.lst)
(h2) LVM volume naming (/etc/fstab)

On my current systems, I usually have the root file system on /dev/hda1, with /dev/hda2 being a PV which is the only PV of a VG vg0, which in turn has LVs named home, var and usr.

This setup has a bunch of disadvantages.

It is necessary to derive from the standard setup, when RAID or crypto is used. In these cases, the root fs needs to be in LVM as well, and hda1 is /boot.
LVM setup breaks in recovery and/or migration scenarios, when the disks from one server are connected to another one due to two VGs named vg0 being present. These situations are solveable via lvrename per UUID though.
Migration to libata is painful since the dreaded “hda” string lurks in half a dozen places, and Debian grub does not really cleanly support having different kernels that need different root= clauses on their command line.

Thankfully, there is a number of possible solutions:

(l1) Mount the root fs with UUID
- - UUID needs to be adapted in /etc/fstab and grub/menu.lst if file system is rebuilt.
- - mount-per-UUID is a function of the Debian initrd, mechanism nonportable, initrd needed
- + no conflicts when a server can access disks of another system, as UUID are unique.
(l2) Mount root fs with label (all root fsses have the same label)
- - Conflicts when disks are moved between servers, making it possible to boot the wrong system.
(l3) Mount root fs with a host-specific label
- - When the system (and the root fs) is renamed, /etc/fstab and grub/menu.lst need to be adapted.
- + no conflicts when disks of more than one server are plugged in.
(l4) VG is named identically on all servers
- - Manual intervention is necessary (see above) if another server’s disks are placed into one server.
- + Backup and other disk related scripts can be configured identically in all systems.
(l5) VG is called like the server
- - Attention needed when renaming a system (/etc/fstab needs to be adjusted).
- - Backup and other disk related scripts need to be configured differently on each system, no standard config possible.
- + no conflicts in the “more than one set of disks in a server” case.

I am pondering about a solution, but suspect that this is totally overengineered.

(l1) Root fs is mounted via label, so that /boot/grub/menu.lst only needs to be edited once during syste installation. After migration to grub 2, a hook script (if grub2’s update-grub finally supports hooks), the root FS label can be automatically generated. molly-guard refuses to boot the system when the root FS label from the boot manager configuration is not identical to the currently mounted root fs’ label, thus forcing to boot with the current root fs or not to boot at all. Do I need to call blkid -g in that case?
(l2) /etc/fstab is identical on all systems and has entries like
- /dev/disk/localhost/usr /usr ext3 defaults
The symlinks in /dev/disk/localhost are generated by a run level S (27) init script (or can this be accomplished by udev?) from /dev/mapper/$(uname -n)--usr, so that the VG is always named like the host. Renaming the VG needs a rescue system anyway, so that’s not a real loss.

Did I miss something? Is this a realistic solution? How do you handle this issue? Comments to this article will be open for quite a while.

LVM regelt verschärft

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 27 May 2008 15:00:00 +0200

Ich glaube, ich erwähnte es schon, aber LVM ist einfach cool. Ich bereue keinen Meter, schon seit 2002 LVM grundsätzlich auf jedem Linux-System das ich installiere einzusetzen. Damals war ich hauptsächlich scharf darauf, Festplattenpartitionen mit “sprechenden” Namen zu haben, die obendrein auch noch unabhängig davon sind, mit welcher Schnittstelle eine Platte an das System angebunden ist.

Aber auch Snapshots und die Möglichkeit zum Resize haben mir inzwischen schon öfter ~~den Arsch gerettet~~die Arbeit erleichtert.

Im Zuge meiner aktuellen Hardwarebasteleien hatte ich die Aufgabe, ein System von einer SATA-Platte auf eine PATA-Platte umziehen zu lassen. Das hätte man zwar natürlich auch mit einer tar | tar-Pipe oder rsync machen können, aber mit LVM ist es doch viel cooler (und man kann kein --numeric-owner und/oder --numeric-ids vergessen, was mein Lieblingsfehler ist).

Man fahre das System herunter, um die Zielplatte dazuzuhängen. Dann partitioniere man die Zielplatte, lege eine PV an und erweitere die VG des existierenden Systems um die neue PV (vgextend vg0 /dev/hdc1, zum Beispiel). Als nächstes weise man das System an, alle Daten von der “alten” PV herunterzuschieben (im Falle, dass die alte PV /dev/sda1 ist, zum Beispiel mit pvmove /dev/sda1). Das dauert eine Weile, also möchte man den pvmove-Aufruf eventuell mit --interval 30 garnieren, um alle 30 Sekunden darüber informiert zu werden, wie weit der Plattenshredder inzwischen fortgeschritten ist.

Während der gesamten Aktion kann das System, dessen Installation oder dessen Daten da gerade verschoben werden, im vollständigen Produktivbetrieb laufen, was natürlich für einen Server mit wichtigen Aufgaben sehr, sehr praktisch ist. Hat man Hardware, mit der Hotplugging von Festplatten möglich ist, geht die Migration auf eine neue Platte komplett ohne Betriebsunterbrechung. Natürlich bleiben Dateiattribute und sogar die Inode-Nummern unverändert, was bei einer hostbasierten intrusion detection die Menge der nach der Migration erzeugten Fehlalarme deutlich übersichtlicher macht.

Ist das pvmove abgeschlossen, entfernt man die “gehende” PV aus der Volume Group (vgreduce vg0 /dev/sda1, das ist wichtig. Unvollständige VGs mag der LVM auch dann nicht, wenn dort keine Daten mehr drauf liegen) und kann dann die alte Platte aus dem System entfernen.

Wo so viel Licht ist, ist natürlich auch Schatten: pvmove heißt pvmove und nicht pvcopy. Das bedeutet insbesondere, dass man die Daten wieder zurückverschieben muss, wenn sich herausstellt, dass man die neue Platte verkehrt partitioniert hat. Beim konventionellen Arbeiten würde man einfach die Kopieraktion wiederholen und hätte die Daten nur zweimal und nicht dreimal über die Schnittstelle geschlenzt.

Außerdem tun sich Linuxe etwas schwer mit dem Booten von LVM-basierten Systemen. Ich hatte jahrelang eine ausgeprägte initrd-Phobie, was mich dazu zwingt, das root-Filesystem mit typischerweise 200 MB Größe außerhalb des LVM liegen zu haben. Damit ist der Traum, auf hotplug-fähiger Hardware zum Plattenwechsel komplett ohne Downtime auszukommen, ausgeträumt, denn mindestens zum klassischen Umkopieren des Root-FS muss gebootet werden, außerdem macht man diese Kopieraktion am besten aus einem Rettungssystem. Aber da ich zeitlebens noch kein System mit hotplugfähigen Platten (außer USB, aber da hab ich das auch noch nie probiert) in den Fingern hatte kann ich damit auch leben.

Wenn man mutig ist und mit einer initrd booten kann, braucht man nur /boot außerhalb des LVM. Dann geht die Migration komplett ohne Downtime, denn /boot aushängen und kopieren kann man auch im laufenden Produktivsystem. Allerdings will man vermutlich dann auch mal booten, um zu gucken, ob man auch alles richtig gemacht hat - im Zweifelsfall ist sonst der nächste Boot in einer Streßsituation und man darf dann auch noch mit den Fehlern kämpfen, die man beim Umkopieren gemacht hat.

Grub2 kann dem Vernehmen nach auch aus einem LVM booten; sollte Grub2 wider erwarten in diesem Leben nochmal benutzbar werden, kann man sich auch das außerhalb des LVM liegende /boot sparen. Aber ich fürchte, bis dahin wird noch eine Menge Wasser durch die Neckarschleusen fließen.

Noch zwei Worte zum Thema initrd-Phobie: Die war weitgehend unbegründet. Debians initrd-Tools sind in Form von initramfs-tools inzwischen so flexibel und ausgereift, dass der Spaß erstaunlich schmerzarm abläuft und man im Normalbetrieb keine Fußangeln vorfindet. Das funktioniert einfach. Aber bis ich meine Standard-Server-Installation auf initrd umstelle, muss noch etwas Zeit vergehen.

Mietserver-Recovery mit veraltetem Rescuesystem

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 24 Mar 2008 23:07:00 +0100

Den First Dedicated Power Server S Limited Edition benutze ich seit ziemlich genau einem Jahr als Entwicklungssystem. Da die Kiste ausschließlich verschlüsselt mit der Außenwelt spricht, sind die Schwächen im Netzwerksetup des Hosters für meine Anwendung irrelevant. Als nicht irrelevant zeigten sich vor einigen Wochen die Macken im Rescuesystem, als ein Umstieg auf neue Hardware anstand.

Mein Server hat im Herbst letzten Jahres angefangen, SMART-Fehlermeldungen zu werfen, und Anfang Februar wurde es mir dann zu bunt, so dass ich ein Ticket beim Hoster aufgemacht habe. Der Hoster findet bei einer oberflächlichen Prüfung des Systems, die mit einem knappen halben Tag Downtime verbunden war, keine Fehler und tauscht mir kulanterweise das PATA-Kabel. Leider hilft das nicht, die SMART- und CRC-Fehler im Syslog tauchen schnell wieder auf.

Als nächstes versucht der Hoster, die Schuld auf mein System zu schieben (“Fehlerhaftes Dateisystem oder Bugs im verwendeten Kernel”) und möchte, dass ich den Server neu aufsetze. Ich versuche das erstmal zu vermeiden und versuche das Problem mit dem Rescue-System zu reproduzieren. Das erweist sich aber als leichter gesagt als getan, denn das Rescuesystem ist - ich berichtete - so alt, dass ich damit meine Filesysteme nicht eingehängt bekomme. Und durch irgendwelche dd-Übungen ist das System nicht zum Werfen von CRC-Fehlern zu bringen.

Also rsynce ich die Daten zähneknirschend auf einen anderen Server (um mir das Restore vom Wohnungs-Backup über mein dünnes ADSL zu ersparen), mache eine Neuinstallation auf das Uralt-Standardimage des Anbieters, update auf aktuelles Debian etch mit security-Updates und beginne meine Daten draufzukopieren. Keine fünf Minuten später beginnen wieder die CRC-Fehler.

Nun ist der Hoster auch überzeugt und bietet mir den Tausch gegen eine komplett neue Maschine an, die dann auch eine neue IP bekommt. Das stört mich nicht, da ich das System ja nur inten verwende, also stimme ich zu. Leider ist es nicht möglich, Zugang auf beide Maschinen gleichzeitig zu bekommen; zuerst wird die alte abgeschaltet und dann für die neue Zugangsdaten generiert. Am Abend desselben Tages kommen die Zugangsdaten für die neue Kiste; ab dem ersten Kontakt bis hier sind sechs Tage vergangen.

Die Zugangsdaten für den neuen Server teilen mir mit, dass ich mich in das Rescuessystem mit grml@ip-adresse einloggen soll. Das funktioniert allerdings nicht, und das auf Port 22 sichtbare Banner mit dem String “Debian woody” lässt vermuten, dass ich es hier auch nicht mit einem grml zu tun habe, sondern mit dem “alten” Rescuesystem. Nach einer Stunde sind dann auch die Zugangsdaten in das System konfiguriert und ich kann mich endlich - als root - anmelden.

Wie schon im Servertest erwähnt, ist das Rescesystem von First Dedicated uralt. Es basiert irgendwo auf Debian woody, hat weder LVM-Support im Kernel noch die Userspace-Tools installiert und läuft noch mit Linux 2.4. Damit direkt mein LVM- und Linux-2.6-basierendes System wieder draufzuklatschen ist illusorisch. Also anders.

Ich entschliesse mich, wie schon bei einem anderen Hoster neulich durchgespielt, ein grml-small in die swap-Partition zu installieren. Aber dann kommt mir die Idee, dass das gar nicht not tut: Ich habe doch ein nicht im LVM liegendes ext2-Filesystem, nämlich das System, das im Produktivbetrieb als root eingehängt ist. Spricht eigentlich nichts dagegen, das grml dort abzulegen - dann steht es schneller zur Verfügung, wenn im Notfall das Root-Filesystem noch da ist. Wenn es nicht mehr da ist, kann man dann immer noch den Stunt mit dem swap-Filesystem machen.

Also wird schwupps die Platte partitioniert, das root-Filesystem auf hda1 angelegt und dessen Inhalt aus dem Backup zurückgeschoben. Nach /boot/grml kommt der Inhalt einer grml-small-CD. grml-medium hatte ich zu dem Zeitpunkt noch nicht ausprobiert; der Trick hätte aber nach den einschlägigen Erfahrungen aus der Erstellung meines Universal-Boot-Sticks auch mit grml-medium funktioniert.

Die für grml-small gültige Boot-Eintragung lautet:

title           grml
root            (hd0,0)
kernel          /boot/grml/linux26 toram grml_dir=/boot/grml/GRML/ grml_name=GRML toram ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml ssh=M9flN0A1
initrd          /boot/grml/minirt26.gz

und ich schätze, dass die für grml-medium irgendetwas rund um

title           grml-medium
root            (hd0,0)
kernel          /boot/grml/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs lang=us
boot=live noeject noprompt keyboard=de
initrd          /boot/grml/boot/grmlmedium/initrd.gz

heißen müsste. Das hab nich aber nicht ausprobiert.

Nun nur noch grub auf der Platte installieren. Unter Debian liegt das grub-Binary in /usr und steht somit im vorliegenden Zustand des Systems nicht zur Verfügung; das Rescuesystem hat kein grub. Also schwupps die binäre grub-Package aus Debian stable gezogen, mit dpkg-deb ausgepackt und... festgestellt, dass die Libraries des Rescuesystems zu alt sind um das dynamisch gelinkte grub-Binary auszuführen. Ich spare mir den Bugreport “please build a new package with statically linked grub”, weil grub in Debian nicht mehr wirklich gepflegt wird - die Maintainer sind der Meinung, dass man die Arbeit besser in grub 2 stecken sollte, und ich bin der Meinung, dass bis zur rudimentären Benutzbarkeit von grub 2 noch ein wenig Wasser den Neckar wird herunter fliessen müssen.

Statt dessen wird /boot/grub in /boot/grub-backup umbenannt, ein historisches grub aus woody ausgepackt, die stages nach /boot/grub geschoben, menu.lst kopiert und auf der grub-shell installiert. Da der Server keine serielle Konsole hat, muss mit dem default-Keyword gearbeitet werden (die Einträge zählen ab Null, #451709), und schwupps läuft das grml.

Der Rest ist schnell erzählt: LVM bauen, Filesysteme anlegen, Daten zurück-rsyncen, chroot ins frisch restorete System, IP-Adresse anpassen, /boot/grub nach /boot/woody-grub umbenennen, /boot/grub-backup zurückschieben, “aktuellen” grub neu installieren, booten und Produktivbetrieb aufnehmen. Das grml bleibt da für zukünftige Aktionen liegen, mit dem aktuellen Grub lässt es sich ja auch nach Anpassung des Default-Wertes in der menu.lst kurzfristig booten.

using grml to prepare LVM surgery

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 29 Mar 2007 00:00:52 +0200

One of my dedicated servers was in bad need of major LVM surgery today. Since the rescue system delivered with the server by the housing provider suffers from lack of LVM support, I needed to pull a creative stunt with grub and grml to accomplish this.

The dedicated server rented from strato is the Box I tested in a different article. Installing the LVM-based Debian system via the LVM-less rescue system involved first installing without LVM in the partition which was originally supposed to be swap, booting the just installed system and using this temporary system to finally bootstrap the target.

I had originally planned to go this way again in case rescue should become necessary. Today, I checked first whether the provider supplied rescue system had improved in the mean time (which it hadn’t), and I didn’t feel like installing a new temporary system. Instead, I decided to go through a different route, using grml.

grml is extremely versatile regarding boot. All you need is to get the grml kernel to boot and point it towards the grml initrd, and the initrd automatically searches the available drives for the compressed file system image, mounts it and continues the boot process. This was the point where I hooked myself into grml. I put an ext3fs on the swap partition and copied the contents of a grml CD to that partition. After thinking a while about how to get ISOLINUX to boot this grml, I remembered that the disk already has grub installed, and decided to use grub to boot grml.

This was possible because the provider offers a serial console for the machine. If no serial console had been available, things would have been a lot harder since there would be no feedback and one would have to talk to grub via offline editing of menu.lst. Thanks to the serial console, things were a lot faster.

Booting grml via grub is actually easy. After finding out which partition grml is on (find /linux26) and setting this partition as root, all you need is “kernel /linux26 ramdisk_size=100000 init=/etc/init lang=us BOOT_IMAGE=grml console=ttyS0,57600n8”, “initrd /minirt26.gz” and finally “boot”.

The “57600” given on the kernel command line was actually the hardest part: Strato operates the serial console at unusual 57600 bps, and grml’s serial console feature starts mgetty with hard-coded 9600 bps. The rather frustrating symptom was that you can watch grml booting, with “Finished execution of main grml startup” as the last sign of life. Knowing that there is a login prompt waiting for you at the wrong baud rate.

After talking to Mika from the grml team for some minutes, we decided to take two “roads” to solve the issue. Mika hacked grml’s startup process to parse the baud rate to be used for mgetty from the kernel command line. Since I couldn’t wait for Mika’s fix, I used a grml.sh script to put a fixed mgetty.config over the file contained in grml. After fixing some stupid mistakes on my part, I finally received my grml login prompt and could start with the LVM surgery.

Grml is a perfect tool for such tasks since it is extremely flexible and not selective in which medium and partition types it can boot from. It has saved me a lot of grief today and has helped me in solving a difficult problem.

Oh, btw, pvmove --alloc anywhere can move a logical volume inside a pysical volume without the need of a temporary physical volume, and it is thus possible to “manually” defragment a physical volume in order to allow more clean resizing of logical values. While it is debateable whether this does really make sense, it satisfies my sense of order to have an LVM setup unfragmented.

LVM unter Linux

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 16 Jun 2005 03:07:17 +0200

LVM rockt. Gerade mal wieder gemerkt, als in dem von mir betreuten Newsserver die (einzige) Platte ihr Ableben angekündigt hat. 40 GB Daten im laufenden Betrieb von einer alten auf eine neue Platte schieben ist einfach sexy. Die einzige Downtime hatte ich mir dadurch eingehandelt, dass die Overviews durch die kaputte Platte beschädigt waren, und deswegen ein makeh*story fällig war.

Diese Gelegenheit nutze ich, einen alten Artikel zum Thema LVM für mein Blog zu recyceln.

Was ist LVM

Der Logical Volume Manager ist seit späteren 2.4-Versionen Bestandteil des Linux-Kernels. Zusätzlich zum Kernelcode sind Userspace-Tools notwendig, mit denen die Verwaltung durchgeführt wird.

LVM führt zwischen der Plattenpartition (z.B. /dev/hda1) und dem Filesystem (z.B. /usr) zwei weitere Indirektionsebenen ein, die für beeindruckende Flexibilität sorgen.

Beim klassischen Filesystemlayout liegen die Ebenen wie folgt übereinander:

Mountpoint (z.B. /usr)
Filesystem (z.B. ext3fs)
Raw Device (z.B. /dev/hda1)
Plattenpartition
Platte

Eine Veränderung des Filesytems schlägt sofort bis auf die Physik der Platte durch.

Bei einem LVM-System sieht der Stapel wie folgt aus:

Mountpoint (z.B. /usr)
Filesystem (z.B. ext3fs)
Logical Volume [LV] (z.B. /dev/vg0/usr)
Volume Group [VG] (z.B. /dev/vg0)
Physical Volume [PV] (z.B. /dev/hda1)
Raw Device (z.B. /dev/hda1)
Platte

In Text gesprochen:

Auf einem Mountpoint ist ein Filesystem eingehängt.
Ein Filesystem liegt auf einer Logical Volume.
Auf einer Logical Volume liegt immer genau ein Filesystem!
Eine Logical Volume ist Element einer Volume Group.
Eine Volume Group hat ein oder mehrere logical Volumes.
Eine Volume Group besteht aus einer oder mehreren Physical Volumes.
Eine Physical Volume ist eine Festplattenpartition mit Partitionstyp 8e.
Bei einheitlicher Aufteilung auf logical volumes sind die Namen der logical volumes überall gleich, unabhängig vom Plattentyp und deren Organisation.
Host-based intrusion detection einheitlich konfigurierbar
Plattenplatzüberwachung einheitlich konfigurierbar.

Vorteile

LVM

Nimmt Verantwortung aus der Plattenpartitionierung
Ermöglicht die Partitionierung von Software-RAID-Devices
Symbolische Namen für filesystem tragende Volumes (/dev/vg0/usr) sorgen für übersichtliche /etc/fstab und fließend interpretierbare /proc/mounts
nie wieder unpassende Namen, da Umbenennen möglich
Vergrößern und verkleinern von Volumes ist möglich
mit einem online resizebaren Filesystem ist Größenänderung von Dateisystemen im laufenden Betrieb möglich.
Kopieren einer Volume (z.B. zum Plattenwechsel) ist im laufenden Betirieb möglich
Bei Erweiterungen muss der Rechner nur zweimal kurz (zum Einbau der neuen und nach dem Kopieren zum Ausbau der alten Platte) ausser Betrieb gehen, bei hotplug-tauglichen Systemen gar nicht.
Während des Kopiervorgangs ist Lese- und Schreibzugriff auf die Platte möglich.
Migration von unter Kernel 2.4 erzeugten Volumes auf Kernel 2.6 ist - inklusive eines schmerzfreien Rückwegs möglich.

Nachteile

Funktioniert nicht mit älteren Kernels
Braucht die Userspace-Tools, die sich obendrein auch noch von der Kernelversion abhängig unterscheiden
Root-File-System auf LVM funktioniert nur mit initrd. Deswegen lege ich das Root-File-System nicht auf eine LVM-Volume. Das tut mir nicht weh, da das root-FS auf meinen Sstemen eh “winzig (200 MB)” ist.