Hallo zusammen Ich möchte auf meinem Ubuntu 18.04 Server die Ordner /home und /var auf ein logical volume mounten. Dabei sollen in diesem Ordner grpquota und usrquota aktiviert sein. Ich habe dies bereits einmal versucht umzusetzen, bin aber gescheitert, und musste das OS neu aufsetzen. Deshalb frage ich nun hier nach, ob sich jemand auskennt damit. Angenommen ich habe folgende Struktur: VolumeGroupA ---LogicalVolumeA: Mounted on \ Raid ---VolumeGroupB ------LogicalVolumeB Nun möchte ich dass \home und \var auf LogicalVolumeB liegen mit grpquotas und usrquotas. Dabei habe ich zwei mögliche wege "gesehen": LogicalVolumeB auf z.B. \serverdata mounten und nun \serverdata\home auf \home mounten und \serverdata\var auf \var mounten. Dies auch so in die fstab eintragen. Ist allerdings etwas verschachtelt. Die andere Variante: /dev/mapper/VolumeGroupB-SrvData/home auf /home mounten und /dev/mapper/VolumeGroupB-SrvData/var auf /var mounten Zudem frage ich mich, welches die richtigen Einträge in der fstab sind? Habe mit dem Mounten von LVs und Quotas noch nicht so viel erfahrung. Hoffe jemand kann mir hier ein paar Hinweise geben. Vielen Dank.
Hier ist noch meine UUID /dev/mapper/server--vg-serverdata: UUID="9w63s5d2-w321-632s-ee63-82b1cf1a84ee" TYPE="ext4" Könnte ich nun einen Eintrag in fstab wie folgt machen:
1 | UUID=9w63s5d2-w321-632s-ee63-82b1cf1a84ee /home ext4 quota,usrquota,rw,data=ordered,grpquota,relatime 0 0 |
2 | |
3 | UUID=9w63s5d2-w321-632s-ee63-82b1cf1a84ee /var ext4 quota,usrquota,rw,data=ordered,grpquota,relatime 0 0 |
?
:
Bearbeitet durch User
In /dev werden doch Symlinks angelegt: /dev/VolumeGroupA/LogicalVolumeA Die kannst Du auch in die fstab eintragen. Das ist gut lesbar, und man weiß, was man da gemacht hat. Dazu dann die Parameter ext4 defaults,usrquota,grpquota 0 2 relatime brauchst Du nur, wenn Du Schreibzugriffe reduzieren willst (weil SSD).
Danke für deine Antwort. Ich darf keinen Fehler machen, sonst muss ich den Server nochmals neu installieren... haha np r. schrieb: > In /dev werden doch Symlinks angelegt: Bei mir steht unter /dev folgendes: /dev/server-vg/ Dort drinn befindet sich eine Datei serverdata (mein Logisches Volume) Dieses ist jedoch kein Directory. Nun frage ich mich, wie ich dieses nun verwenden soll? Etwa so?
1 | /sev/server-vg/serverdata \home ext4 defaults,usrquota,grpquota 0 2 |
und
1 | /sev/server-vg/serverdata \var ext4 defaults,usrquota,grpquota 0 2 |
?
:
Bearbeitet durch User
Holger K. schrieb: > Dieses ist jedoch kein Directory. Nein, es ist ein Symlink auf die Gerätedatei, die der Device Mapper erstellt hat. Den Symlink gibt es zu Deiner Bequemlichkeit, so dass Du nicht "/dev/dm-2" in die fstab eintragen musst (und irgendwann damit falsch liegst). > Nun frage ich mich, wie ich dieses nun verwenden soll? > > Etwa so? > > /sev/server-vg/serverdata \home ext4 defaults,usrquota,grpquota 0 > 2 Ja, genau. Wenn Du den Tippfehler /sev ... korrigierst. ;-)
:
Bearbeitet durch User
Holger K. schrieb: > on \ ... > dass \home und \var ... > /sev/server-vg/serverdata \home ext4 defaults,usrquota,grpquota 0 2 Hör mit den Backslashs auf, das ist kein Windows. Man kann backslashs zwar in Dateinamen verwenden, das Trennzeichen für Pfade ist und bleibt aber /, und nicht \. Du musst das ganze ja auch nicht sofort scharf stellen. Erstelle erstmal einen Ordner in /mnt, z.B. /mnt/home, und schaue mit mount -a ob es geht. Falls ja, kannst du den Reboot testen. Nicht vergessen, die Dateien vom alten /var usw. ins neue zu kopieren (rsync -av var /mnt/var/) (den letzten / bei rsync nicht vergessen, sonst hast du nachher alles in /mnt/var/var/). Und wenn das auch geht, kannst du es wieder unmounten "umount /mnt/home", in der fstab /mnt/home auf /home ändern, und dann wieder mit "mount -a" mounten. Dann wieder den neustart testen. Pass algemein besser auf, was du eingibst, z.B. ist /dev, nicht /sev. Du kannst den Pfad vorher mit stat oder ls nochmal kontrollieren oder nachsehen, z.B. "ls /dev", dann "ls /sev/server-vg/", usw. Ich habe mit LVM noch nichts gemacht, aber sicher kann man die Dinger auch per UUID oder LABEL mounten/in die fstab eintragen. Einfach mit "blkid" nachsehen, und dann UUID=die-uuid-hier, ohne die "" statt dem Devicefile in die fstab. Geht sicher auch mit Labels usw.
Danke für eure Antworten. Eine Frage stellt sich mir noch. Wenn ich nun /dev/server-vg/serverdata /home ext4 defaults,usrquota,grpquota 0 2 und /sev/server-vg/serverdata /var ext4 defaults,usrquota,grpquota 0 2 Gemountet habe, wird dann im ordner bzw. im device serverdata automatisch ein ordner /home angelegt? Oder liegen dann die daten aus dem Ordner /home und die daten aus dem Ordner /var alle "nebeneinander" im "ordner" serverdata? Das wäre ja dann ziemlich schlecht...
Wenn du das gleiche Device zweimal mountest sind an beiden Orten die selben Daten des selben Device. Also entweder separate Partitionen, oder woander Mounten, die Ordner erstellen, und dann entweder symlinks darauf, oder bind mounts, was auch immer einem am meisten beliebt.
DPA schrieb: > woander Mounten, die Ordner erstellen, und dann entweder symlinks > darauf, oder bind mounts, was auch immer einem am meisten beliebt. Das ist ja genau mein Problem, damit kenne ich mich (noch) zuwenig aus. Könntest du dies bitte etwas genauer erläuter? Mein Ziel ist es, die Ordner /var und /home auf mein RAID5 zu bekommen welches ein LogicalVolume server-vg hat und ein LogicalDevice serverdata Muss ich also das Device serverdata zb. in den Ordner /serverdata mounten und dann ein symlink für /var und /home auf /serverdata/var und /serverdata/home erstellen? Wenn ja, funktionieren dann auch die quotas für /home und /var? Und bleibt der symlink auch nach einem reboot bestehen? Danke
Sollen /var und /home auf demselben logical volume liegen? Oder auf zwei verschiedenen?
Holger K. schrieb: P.S.: > welches ein LogicalVolume server-vg hat und ein LogicalDevice serverdata Du vermischst gerade Volume Group, Logical Volume und Device.
Sinn würde doch z.B. machen, wenn Du einer Volume Group (VG) den gesamten RAID5 als Physical Volume (PV) zuteilst. Dann machst Du je ein Logical Volume (LV) für /home und eins für /var. Dadurch bist Du unabhängig in der Wahl Deines Dateisystems und wenn auf oder mit /home oder /var mal etwas Unangenehmes passiert (Schreibfehler bzw. Dateisystemfehler, disk full wegen eines wild gewordenen Prozesses, der Daten ohne Ende schreibt), dann ist nur ein LV davon betroffen. Und das quota willst Du doch sowieso nur auf /home haben, oder?
np r. schrieb: > Sollen /var und /home auf demselben logical volume liegen? > Oder auf zwei verschiedenen? Ja, zwecks übersichtlichkeit, alle relevanten Daten auf einem Volume np r. schrieb: > Du vermischst gerade Volume Group, Logical Volume und Device. Ja, du hast recht
:
Bearbeitet durch User
np r. schrieb: > Sinn würde doch z.B. machen, wenn Du einer Volume Group (VG) den > gesamten RAID5 als Physical Volume (PV) zuteilst. > Dann machst Du je ein Logical Volume (LV) für /home und eins für /var. > Dadurch bist Du unabhängig in der Wahl Deines Dateisystems und wenn auf > oder mit /home oder /var mal etwas Unangenehmes passiert (Schreibfehler > bzw. Dateisystemfehler, disk full wegen eines wild gewordenen Prozesses, > der Daten ohne Ende schreibt), dann ist nur ein LV davon betroffen. > Und das quota willst Du doch sowieso nur auf /home haben, oder? Gute Idee, Ich verwende virtualmin. Dieses benötigt var für mails und config sowie datenbankt, und home für webseiten. Vermutlich brauche ich daher für beide Ordner die quotas (ja ich möchte diese, da nicht nur ich dort webseiten habe) Können sich denn die LogicalVolumes den gesamten Speicher dynamisch teilen? So dass ich die Grösse nicht fix definieren muss?
Holger K. schrieb: > Können sich denn die LogicalVolumes den gesamten Speicher dynamisch > teilen? > So dass ich die Grösse nicht fix definieren muss? Dynamisch nicht. Ein Vorteil von LVM gegenüber starren Partitionen ist, dass die Größen der Partitionen nachträglich sehr leicht manuell verändert werden können. Aber eben manuell. Wenn Du das dynamisch haben willst, könntest Du btrfs subvolumes einrichten. Das läuft aber im Zusammenhang mit quotas noch etwas ruckelig. https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-quota Ich würde das auf einem Produktionssystem nicht machen sondern lieber zwei LVM LVs mit ext4. Einen für /var und einen für /home. Wenn die dann voll werden, bekommst Du das ja rechtzeitig mit und kannst manuell vergrößern. Oder dem Verursacher auf die Zehen steigen.
np r. schrieb: > Ich würde das auf einem Produktionssystem nicht machen sondern lieber > zwei LVM LVs mit ext4. Einen für /var und einen für /home. Wenn die dann > voll werden, bekommst Du das ja rechtzeitig mit und kannst manuell > vergrößern. Oder dem Verursacher auf die Zehen steigen. Ok gute Idee. Zwei volumes, allerdings mit quota? Dann also in etwa so? /dev/server-vg/srvHome /home ext4 defaults,usrquota,grpquota 0 2 und /dev/server-vg/srvVar /var ext4 defaults,usrquota,grpquota 0 2
:
Bearbeitet durch User
Ja. Dieses Mal sind sogar die Tippfehler raus. ;-)
:
Bearbeitet durch User
np r. schrieb: > Ja. Dieses Mal sind sogar die Tippfehler raus. ;-) super, vielen Dank! Nun noch eine Frage, kann ich das aktuelle home in z.b. home-orig umbenennen, selbiges mit var. dann ein neues home und var erstellen und die pfade mounten. Nun mit rsync die daten aus orig kopieren. Mehr müsste es nicht brauchen richtig?
Habe nun den home folder erfolgreich verschoben. Beim var folder hingegen gab es probleme. Mit rsync -av habe ich immer einen error 23 bekommen. Habe gelesen, man müsse in den init 1 mode booten damit keine services laufen? Gibt es andere alternativen? bzw. welche folder von var muss ich tatsächlich kopieren und welche sind unwichtig für das system?
Holger K. schrieb: > Gibt es andere alternativen? Exitcode 23 bedeutet, dass einige Datein nicht kopiert wurden. Die Ursache der Probleme dürfte sein, dass einige Dateien noch im Zugriff sind. Du kannst statt runlevel 1 auch einfach mal versuchen möglichst viele Dienste zu stoppen (mysql, apache, ...) die haben dort nämlich ihre Datenverzeichnisse Die sauberste Variante wäre es, dein System von der Ubuntu CD aus zu starten und dann aus der "Rescue Shell" die Daten zu kopieren. Du musst allerdings ggf. die Laufwerke von Hand mounten (ich bin mir bei Ubuntu gerade nicht sicher)
Mit dem (Un-)Kenntnisstand solltest du eher auf alle "Advanced Features" eher verzichten. Deine Daten werden es dir danken. Kauf dir einen HW-Raid-Controller und lass den die Arbeit machen. Und Quotas brauch man eigentlich auch nicht. Jeder FS hat im normalerweise eine 5 %-Reserveschaltung. Die kann man dann im Notfall einfach auf 0 setzen.
schlaubi schrieb: > Mit dem (Un-)Kenntnisstand solltest du eher auf alle > "Advanced Features" eher verzichten. Deine Daten werden > es dir danken. Dann werde ich das alles auch in 20 Jahren noch nicht verstehen. Das ist wohl der falsche Ansatz.
> Dann werde ich das alles auch in 20 Jahren noch nicht verstehen. > Das ist wohl der falsche Ansatz. Zum Experimentieren kann man einen Virtualisierer seiner Wahl benutzen. Da darf und kann es dann auch mal Bumm machen. Und Verstehen setzt Verstaendnis voraus. Das erwirbt man u.a. durch Lesen der entsprechenden Grundlagenliteratur. Zu meiner Zeit waren das der Bourns und der Gulbins. Als Uebungsaufgabe kannst du ja mal drueber nachdenken, wieso Quotas ueberwiegend sinnfrei sind. Ein Teil der Erklaerung habe ich ja schon geschrieben.
schlaubi schrieb: > Deine Daten werden es dir danken. > > Kauf dir einen HW-Raid-Controller Schlechte Idee, wenn der ausfällt kommst du an die Daten nicht mehr ran, ausser du findest nochmal genau das gleiche Modell. SW-Raid ist da besser, da spielt das keine rolle mehr. Holger K. schrieb: > Ich darf keinen Fehler machen, sonst muss ich den Server nochmals neu > installieren... haha Es gibt viele Methoden, einen nicht mehr bootenden Server wieder instand zu setzen. z.B. kann man in den single user mode booten. Wenn das nicht geht, kann man beim boot direkt /bin/bash starten lassen, ohne jeglichen init kram davor. Und wenn auch das nicht geht, kann man noch von einer live cd aus ein chroot durchführen. Sobald man dann so wieder eine Shell hat, kann man seine Fehler wieder korrigieren. Das ist zwar anfangs etwas umständlich, aber man gewöhnt sich dran.
> Schlechte Idee, wenn der ausfällt kommst du an die Daten nicht mehr ran, > ausser du findest nochmal genau das gleiche Modell. Ja, dann muesste die IT quer durch die Welt schlecht sein. Die benutzen sowas naemlich. So nicht ohnehin nur ein SAN, was ja auch nur ein gigantischer Controller ist, Zugang zu Platten/SSD vermittelt. Und, oh Wunder: Wenn man nicht das grad das seit 20 Jahren ausgelaufende Modell von Spintronics aus Hintertupfingen nimmt, wird man auch Ersatz finden. > SW-Raid ist da besser, da spielt das keine rolle mehr. Das mag fuer Mirroring und Striping ja noch gelten. Bei komplexeren Algorithmen ist das in einem dedizierten Controller sicher besser aufgehoben. Das das durchaus Rechenleistung erfordert, kann man uebrigens seht gut an der "Waermeabgabe" einiger RAID-Controller sehen. Die Methoden nicht mehr zugreifbare Systeme zu recovern, sollte man sich ohnehin rechtzeitig aneignen.
schlaubi schrieb: >> Schlechte Idee, wenn der ausfällt kommst du an die Daten nicht mehr ran, >> ausser du findest nochmal genau das gleiche Modell. > > Ja, dann muesste die IT quer durch die Welt schlecht sein. > Die benutzen sowas naemlich. Vor 20 Jahren hättest du noch Recht gehabt. Aber seit gut 10 Jahren ist Software-RAID performancemäßig gleichauf und bietet funktionale Vorteile. Wenn du nicht gerade ein Nischen-OS verwendest (Windows?) dann ist Software-RAID heute das Mittel der Wahl. > So nicht ohnehin nur ein SAN, was ja auch nur ein gigantischer > Controller ist Die Plattenschränke in einem SAN machen das alles per Software. >> SW-Raid ist da besser, da spielt das keine rolle mehr. > > Das mag fuer Mirroring und Striping ja noch gelten. > Bei komplexeren Algorithmen ist das in einem dedizierten > Controller sicher besser aufgehoben. Was soll das sein, RAID-5? Das ist Pillepalle für heutige CPU. Linux md testet die Performance der Algorithmen beim Boot. Auf einer Mittelklasse CPU (Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz) sehe ich hier:
1 | [ 2.117168] raid6: sse2x1 gen() 10751 MB/s |
2 | [ 2.185162] raid6: sse2x1 xor() 8403 MB/s |
3 | [ 2.253166] raid6: sse2x2 gen() 13684 MB/s |
4 | [ 2.321163] raid6: sse2x2 xor() 9196 MB/s |
5 | [ 2.389161] raid6: sse2x4 gen() 15791 MB/s |
6 | [ 2.457160] raid6: sse2x4 xor() 11121 MB/s |
7 | [ 2.525157] raid6: avx2x1 gen() 20954 MB/s |
8 | [ 2.593158] raid6: avx2x2 gen() 24250 MB/s |
9 | [ 2.661155] raid6: avx2x4 gen() 28234 MB/s |
10 | [ 2.661658] raid6: using algorithm avx2x4 gen() 28234 MB/s |
11 | [ 2.662124] raid6: using avx2x2 recovery algorithm |
Das sind 28 Gigabyte pro Sekunde, was die CPU da verarbeiten kann. Da ist noch sehr viel Luft, bis das Backend das auch wegspeichern kann. Die Rebuild-Rate des RAID-6 wird durch die Geschwindigkeit der Platten limitiert. Die CPU dreht Däumchen dabei. Tatsächlich habe ich auf dem RAID-6 dann noch LVM mit einem LUKS Container, exportiert per NFS und durch alle Schichten hindurch bin ich immer noch bei mehr als 120MB/s, was dummerweise das Limit des Netzwerks ist. > Das das durchaus Rechenleistung erfordert, kann man uebrigens > seht gut an der "Waermeabgabe" einiger RAID-Controller sehen. Noch ein Punkt, der gegen diese Dinosaurier spricht. Ich habe vor einem halben Jahr auch so ein Teil entsorgt. Ist wohl ein i960 da drauf. War mal ein schicker Prozessor. Vor 20 Jahren. Die Zeit geht weiter. Die Server-CPU hat nicht nur mehr Dampf, sie hat auch mehr RAM. Und wenn die Schichten über dem Blockdevice (LVM, Filesystem) das physikalische Layout des RAID kennen (stripe size, stride) dann können sie die Zugriffe nochmal extra optimieren.
Axel S. schrieb: > Wenn du nicht gerade ein Nischen-OS verwendest (Windows?) dann > ist Software-RAID heute das Mittel der Wahl. Ein weiteres solches Nischen-OS ist ein VMware-Host mit lokalem Speicher statt SAN. Es gibt Anwendungsfälle, in denen diese Konstellation Sinn ergibt. > Die Plattenschränke in einem SAN machen das alles per Software. Und zwar schon seit recht langer Zeit. > Die Rebuild-Rate des RAID-6 wird durch die Geschwindigkeit der Platten > limitiert. Bei den Plattenschränken eher von der Bandbreite der Anbindung als von der Geschwindigkeit der Disks. Da kann es sein, dass zig Disks durch 12Gb SAS oder 16Gb Fibre-Channel durch müssen. Bei SSDs ist diese Diskrepanz besonders krass. > Noch ein Punkt, der gegen diese Dinosaurier spricht. Ich habe vor > einem halben Jahr auch so ein Teil entsorgt. Ist wohl ein i960 da drauf. > War mal ein schicker Prozessor. Vor 20 Jahren. Die Zeit geht weiter. Wobei RAID Controller dieser Ära zusätzliche Hardware zur Unterstützung der RAID Funktion drauf hatten. > die Schichten über dem Blockdevice (LVM, Filesystem) das physikalische > Layout des RAID kennen (stripe size, stride) dann können sie die > Zugriffe nochmal extra optimieren. Wobei das bei SSDs an Bedeutung verliert.
:
Bearbeitet durch User
schlaubi schrieb: > Bei komplexeren Algorithmen ist das in einem dedizierten > Controller sicher besser aufgehoben. COW Filesysteme wie ZFS und brtfs integrieren sowohl flexiblen Umgang mit Volumes (LVM) als auch Redundanz (RAID) direkt ins Filesystem. Getrennte Layer wie ext4 auf LVM auf swraid/hwraid ergeben dann ausgesprochen wenig Sinn. Ein Trend hier ist die Trennung von Application-Server (oder Virtualisierungshost) vom Filesystem in Form eines NAS-Systems.
:
Bearbeitet durch User
Axel S. schrieb: > Das sind 28 Gigabyte pro Sekunde, was die CPU da verarbeiten kann. Da > ist noch sehr viel Luft, bis das Backend das auch wegspeichern kann. Und das vmtl pro Kern. Ist man schneller als die RAM-Bandbreite von 25,6 GB/sec, gibts nur noch einen Schönheitspreis. ;-)
Holger K. schrieb: > schlaubi schrieb: >> Mit dem (Un-)Kenntnisstand solltest du eher auf alle >> "Advanced Features" eher verzichten. Deine Daten werden >> es dir danken. > > Dann werde ich das alles auch in 20 Jahren noch nicht > verstehen. Das ist wohl der falsche Ansatz. Naja, ich verstehe Deinen Ansatz ohnehin nicht ganz. Willst Du "alles verstehen" oder willst Du ein konkretes Problem lösen? Ich habe in 25 Jahren privater Linux-Nutzung LVM noch nicht vermisst. Jeder Computer bekommt bei mir zwei physische Platten (Systemplatte, Datenplatte -- beide in Wechselrahmen), alle Platten werden ähnlich partitioniert (viele kleine Partitionen für das Betriebssystem, wenige große für die Daten). /home hat eine eigene Partition auf der Datenplatte, die allen installierten Systemen zu Verfügung steht und auch ganz entfernt werden kann, wenn ich am System herumbastele. Das System mag primitiv sein, aber es hat den unschlagbaren Vorteil, dass ich es auch in zwei, drei Jahren noch verstehe, wenn wieder einmal die Zeit der Bastelei gekommen ist...
A. K. schrieb: >> Die Plattenschränke in einem SAN machen das alles per Software. > > Und zwar schon seit recht langer Zeit. Nun zieht dem schlaubi doch nicht so die Hose aus. Es reicht doch, dass er sich selbst so exponiert hat. Egon D. schrieb: > Das System mag primitiv sein, aber es hat den unschlagbaren > Vorteil, dass ich es auch in zwei, drei Jahren noch verstehe, > wenn wieder einmal die Zeit der Bastelei gekommen ist... Ich finde LVM jetzt nicht so schwer verständlich. Bei mir kommt es auch vor, dass sich die tatsächliche Nutzung eines Rechners gegenüber der ursprünglichen Planung sehr verändert. Natürlich hat man dann ein vollständiges Backup und ein Backup vom Backup (haben wir doch alle, oder? ;-) ) und kann die ganze Geschichte einmal platt machen und neu aufsetzen. Backup restoren und fertig. Allerdings finde ich es angenehmer, Volumes vergrößern oder migrieren zu können, während das System weiter läuft. Aber es gibt eben nicht die eine "richtige" oder "beste" Lösung für alle User und für alle Anwendungen. Teilweise ist es ja auch eine "Geschmacksfrage": Btrfs wäre für viele Systeme, die ich aufsetze eigentlich genau das richtige. Ich habe aber vor >25Jahren mal Daten durch "filesystem corrupt" verloren. Deshalb ist mir der Gedanke unangenehm, dass alle Subvolumes ja zu demselben Dateisystem gehören. Da kann btrfs nichts dafür. Das gab es damals noch nicht. Und mein btrfs Testsystem läuft seit 8 Jahren ohne Probleme. Da gibt's nichts zu meckern. Trotzdem... Nenn es Geschmacksfrage oder Vorliebe. So lange man nicht anfängt (wie weiter oben) Unsinn mit arroganter Pseudologik zu verklären, ist noch alles in Ordnung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.