Arrays exklusiv für Verzeichnis mounten?

[marbus16]

Moinmoin,

bin momentan voll in der Planungsphase für meinen dicken Server (Dual Opteron 875, 10 oder 16GB RAM, reichlich SCSI-HDDs). Die Aufteilung der Arrays habe ich schonmal erledigt - siehe PDF im Anhang.

Jedoch stellt sich mir jetzt die Frage, ob/wie ich bestimmte Arrays exklusiv auf ein Verzeichnis mounten kann?
Z.B. das 108GB Array nur für /home/marbus16/vmware (dieser ordner soll sich auch nicht auf dem 300GB Array sich breitmachen), das 300GB Array dann für /home/marbus16, aber halt nicht für den Unterordner vmware.

Die Trennung von File- VMware- und System-Array ist sehr wichtig, da ich auch bei 3 oder mehr VMs kein Stocken bei der Bereitstellung von Musikdateien haben möchte.

Hoffentlich hab ich das jetzt verständlich genug erklärt

mfG
Marbus

PS: Das System soll auf Debian Etch amd64 aufsetzen, oder auch Lenny wenn es bis dahin (also Mitte Dezember etwa) aus der Beta-Phase raus ist.

 

[-loop-]

Z.B. das 108GB Array nur für /home/marbus16/vmware (dieser ordner soll sich auch nicht auf dem 300GB Array sich breitmachen), das 300GB Array dann für /home/marbus16, aber halt nicht für den Unterordner vmware.

Das geht so nicht wie Du dir das vorstellst!

--> Wenn Du /home/marbus16 mit 300GB mountest,
dann gibt es KEIN /home/marbus16/vmware mehr,
es sei denn der ordner "vmware" wäre gespeichert
auf dem 300 GB Array das Du explizit mountest.

Davon rate ich aber ab, es sei denn Du möchtest das vmware nur gemountet werden kann, wenn /home/marbus16 gemountet ist.

--> Besser wäre:

- /home/marbus16/test (300 GB Array)
- /home/marbus16/vmware (108 GB Array)

So sind die Arrays unabhängig voneinander und es läuft "reibungslos" !

Gruß

-loop-

 

[marbus16]

Wenn ich auf den Server zugreife, lande ich ja direkt im home-verzeichnis des angemdeldeten Benutzers - so solls auch sein, ohne Umwege über Unterordner. Gemountet ist das ja immer, wüsste nicht warum man bei nem Server auch was unmounten sollte.

Soll einfach nur so sein, dass sich /home/marbus16 nur auf dem 300GB Array breitmacht und /home/marbus16/vmware nur auf dem 108GB Array - gemountet ist eh immer allet.

Vielleicht sollt ich ne Runde schlafen, irgendwie ist alles so etwas verworren in meiner Birne :narf:.

 

[liquidnight]

hmm ich weiß net ....

moin.

vom direkten ineinandermounten würde ich dir stark abraten. eher mountest du:
device1 -> /
device2 -> /mnt/r1
device3 -> /mnt/r2
danach mit
# mount -o bind /mnt/r1/marbus16 /home/marbus16
# mount -o bind /mnt/r2/vmware /mnt/r1/marbus16/vmware

btw.: von / auf raid würde ich eher abraten. zu hoch erscheint mir der aufwand bei ausfall des volumes oder um ein backup zu komplett wiederherzustellen. ich würde / auf jeden fall auf ein normales ext3 ziehen, z.b. 4gb müssten locker reichen. die andren 4g der einen platte kannsch dann für var, tmp usw. benutzen. auch würde ich eine stage4 (gentoo-begriff) deines root-filesystems irgendwo als backup halten, wenn die root-platte (respektive das volume) mal komplett ausfällt.

 

[marbus16]

Also RAID muss schon sein. Nicht dass sich die beiden Dell PercII mit ihren 233MHz RISC-Prozessoren langweilen, so ganz ohne RAID . Ahso: Falls das bisher nicht klar war, wird natürlich Hardware-RAID .

Ab 6 oder 8 8GB Platten wirds aber eng mit dem Mounten, ich weiß ja nicht wieviele HDDs es letzten endes sein werden .

So, muss zur Arbeit .

 

[Goodspeed]

vom direkten ineinandermounten würde ich dir stark abraten.

Wieso?
Bzw. ... was ist dann sowas hier

device1 -> /
device2 -> /mnt/r1

Ist doch genau das selbe ...? device2 wird "in" device1 gehängt ...

Also wo ist das Problem, das 300GB Array nach /home/marbus16 zu hängen und das 108GB Array nach /home/marbus16/vmware???

 

[saeckereier]

moin.

vom direkten ineinandermounten würde ich dir stark abraten. eher mountest du: [...]

Warum rätst du dazu, ein Verfahren, dass seit Beginn der Unix-Zeit STANDARD ist nicht zu verwenden? Wenn man das so macht, kann man ja gleich anfangen Laufwerksbuchstaben zu verteilen.. Nur weil es bind mounts gibt, heisst das ja nicht, dass man sie auf Zwang auch verwenden muss..

btw.: von / auf raid würde ich eher abraten. zu hoch erscheint mir der aufwand bei ausfall des volumes oder um ein backup zu komplett wiederherzustellen.

?? Wo ist der Aufwand zu hoch eine neue Platte einzustöpseln und fröhlich grinsend zuzuschauen wie der Inhalt der anderen Platten darauf gespiegelt wird? Mit Hardware Raid sogar *ohne* Downtime.. Das muss eine seltsame Welt sein, wo Nichtstun zuviel Aufwand ist...

 

[marbus16]

?? Wo ist der Aufwand zu hoch eine neue Platte einzustöpseln und fröhlich grinsend zuzuschauen wie der Inhalt der anderen Platten darauf gespiegelt wird? Mit Hardware Raid sogar *ohne* Downtime.. Das muss eine seltsame Welt sein, wo Nichtstun zuviel Aufwand ist...

War ja zu Beginn nicht ganz klar, dass ich 2 dicke Controller zu liegen habe, welche die RAID-Funktionen übernehmen .

Das einzige Problem, das wiederum kein wirkliches ist, wäre die explizite Verwendung der Arrays, sprich dass sich /home/user/vmware auch ja nur auf dem 108GB Array breitmacht. Sobald auch nur etwas auf dem 300GB Array liegt, kann ich wohl das Streamen vergessen. Und 24GB für alles außer /home/user sollten doch reichen für einen Samba- und VMware-Server... Alles weitere wird ja virtualisiert .

Können wir nur noch hoffen dass das nicht mehr als 12 HDDs werden zum Ende, sonst bekomm ich in meinem Stacker Platzprobleme .

 

[Goodspeed]

Das einzige Problem, das wiederum kein wirkliches ist, wäre die explizite Verwendung der Arrays, sprich dass sich /home/user/vmware auch ja nur auf dem 108GB Array breitmacht.

Ja nee ... das haben Unix-artige System so an sich ... wenn die auf dem zugewiesenen Devices keinen Platz mehr haben, packen die Daten irgendwohin, wo grad noch was frei ist ...
Man ... wir reden hier doch nicht von gestapelten Milchtöppen ...

 

[marbus16]

Ja nee ... das haben Unix-artige System so an sich ... wenn die auf dem zugewiesenen Devices keinen Platz mehr haben, packen die Daten irgendwohin, wo grad noch was frei ist ...
Man ... wir reden hier doch nicht von gestapelten Milchtöppen ...

Vielen Dank für die freundliche Auskunft, Herr Moderator...

wenn ich das jetzt richtig gedeutet habe, bleiben die Daten also auf den jeweilig reingemounteten Arrays...

 

[marce]

Das hast Du sehr fein herausgearbeitet.

 

[liquidnight]

Also RAID muss schon sein.

ich meinte: nur die root-partition als einfaches ext3. die arbeitspartitionen, wo deine nutzdaten drauf sind, natuerlich als raid. wenn du schon so viele platten hast.

Warum rätst du dazu, ein Verfahren, dass seit Beginn der Unix-Zeit STANDARD ist nicht zu verwenden?

nur weil man unter unix dateisysteme kreuz und quer ineinandermounten *kann*, heißt das noch lange nicht, dass das auch sinnvoll ist.

wenn du ein dev2 nach /d2 mountest, und ein dev3 nach d2/d3 mountest, dann ist das unsicherer, wie wenn man sie beide in mountpoints innerhalb von / liegen. wenn dir dev2 ausfällt, kommst du an d2/d3/... auch nicht mehr ran. außerdem kann sich das kernel sehr merkwürdig verhalten, wenn es in einem solchen zustand ums reparieren geht.

Wo ist der Aufwand zu hoch eine neue Platte einzustöpseln und fröhlich grinsend zuzuschauen wie der Inhalt der anderen Platten darauf gespiegelt wird?

was du meinst, ist der *einfachste* fehlerfall, nämlich der, dass eine platte alleine kaputtgeht.

es gibt aber noch bei weitem mehr fehlerfälle, die dazu führen, dass die lösung mit dem raid-root alt aussieht. was machst du z.b. wenn du dein raid-root auf einem controller hast, von dem du nur 1 exemplar hast, und das ding zwischendurch mal macken hat, wie z.b. mal hängen bleibt ? und du auf die schnelle das ding nicht ersetzen kannst oder willst, weil es sauteuer ist ? oder wenn du im system probleme mit der spannungsversorgung vermutest und mal 3/4 der last abhängen willst ? was machst du bei blitzschlag, wenn 2 platten des raid5 kaputtgehen ? oder nur eine kaputtgeht, du aber keinen adäquaten ersatz auf die schnelle einsetzen kannst und zu image-datei-im-andren-dateisystem greifen musst ? ganz zu schweigen vom aufwand, wenn man mal ausversehen den bootsektor überschreibt oder grub mal nicht booten will oder so .....

Also wo ist das Problem, das 300GB Array nach /home/marbus16 zu hängen und das 108GB Array nach /home/marbus16/vmware???

das 108gb array wäre dann unsicher angebunden. will heißen unnötig unsicher. --> wenn das 300er array hängt, ärgert man sich, weil man hätte diesen unsicherheitsfaktor einfach vermeiden können.

 

[saeckereier]

Okay, ich sehe ein, dass da vieles dabei ist, was Sinn macht. Aber auf der anderen Seite: Mein Root liegt auf einem RAID-1, das macht vieles davon erstmal irrelevant, denn RAID-1 kann zur Not sofort auf eine Platte reduziert werden. Andere Punkte wie, was mache ich wenn zwei Platten im RAID-5 hopps gehen sind auch egal. Wenn 2 hops sind ist sowieso das Backup fällig. (Bei Root RAID-1 eh nicht relevant)

Den Punkt zum ineinandermounten, wenn der Kernel Probleme bei Wiederherstellungen macht, wenn innerhalb des Mountpoints was anderes gemountet ist, warum sollte er diese bei einem Bind Mount nicht machen? Desweiteren kann man mit den -l und ähnlichen Optionen meist auch die Mounts, die man gar nicht mehr erreichen kann unmounten lassen. Sicherlich komplex, aber wenn man erstmal in dieser Situation ist, dann ist es ohnehin nie einfach. Vor allem würde ich in dem Zusammenhang nicht das Adjektiv unsicher verwenden, denn das ist es nun wirklich nicht.

Aus Interesse: Hast du diese Fälle alle schon durchgemacht?

 

[marbus16]

Ich hab 2 von diesen hüpchen dicken Schinken, also ist Controllerausfall nicht so wild.

Das ist übrigens nur nen privater Server... Also kann der auch mal neu aufgesetzt werden. sollten beide Controller abrauchen, tätschel ich mein Backup und bau nen SATA-RAID auf, das kommt mich dann doch billiger .

 

[liquidnight]

, wenn innerhalb des Mountpoints was anderes gemountet ist, warum sollte er diese bei einem Bind Mount nicht machen?

die bind-mounts lassen sich einfach und ziemlich sicher auflösen. schlimmstenfalls auch lazy.

direkte mounts als die einzigen und verbliebenen hängepunkte des treibers auf ein device sind wesentlich schwerer zu lösen. das bringt schon mal das kernel aus der fassung oder schickt einen mount nach dem anderen in den T oder D modus. D lässt sich dann nicht mehr killen, kein anderer befehl aufs gleiche gerät device läuft währenddessen.

Vor allem würde ich in dem Zusammenhang nicht das Adjektiv unsicher verwenden, denn das ist es nun wirklich nicht. Aus Interesse: Hast du diese Fälle alle schon durchgemacht?

naja, wenn man abwägt: unsicher <--> ähnlich unsicher + umständlich, dann lass ich doch das umständlich gerne weg oder ?

ja, ich hab schon öfters hängende kernel gesehen, die mit unregelmäßig laufenden festplatten zusammenhingen.