Intern: Sonnenuntergang auf dem grünen Planeten

[PuckPoltergeist]

Das via iSCSI auf einer beliebigen mit ISCSI Initator ausgeruesteten Maschine bereitstellen und als Blockdevice für das Filesystem der Wahl verwenden Wie geht das noch mal so auf die Schnelle mit Linux

iSCSI habe ich mit Linux noch nicht genutzt, kann also dazu keine Aussage treffen. Grundsätzlich verhält es sich aber genauso wie jedes andere Block-Device. Man spricht es über das entsprechende Device-File in /dev an. Dabei ist es an sich völlig Rille, ob es lokal oder entfernt, pSCSI, iSCSI, PATA oder SATA ist. Wird alles gleich behandelt.

Ich glaube dir auch ja, dass ZFS ein paar Befehle einspaart. Dass es dadurch einfacher wird, ist aber noch lange nicht gesagt. Und schlussendlich (ich wiederhole mich) schränkt es mich zu sehr in meiner Flexibilität ein. Ich will evtl. ein Volume mit ext3 bestücken, zwei weitere sollen mit XFS genutzt werden und möglicherweise doch mal eins mit ReiserFS. EVMS kann das leisten, durch die strikte Trennung von Volume Manager und Filesystem. Bei ZFS habe ich diese Möglichkeit auf Grund der engen Verdrahtung der zwei Subsysteme eben nicht. Ich könnte dann mit mehreren Volume-Managern hantieren. Aber das wird dann erst richtig kompliziert.

 

[Onkel Homie]

Ist fast wie Tennis gucken hier...ein ziemlich langer Ballwechsel...
Nur auch beim Tennis wird der spannste Ballwechsel mal langweilig und man freut sich wenn dann doch mal wer den Punkt macht...



Also echt...zwei Leute mit so viel Ahnung (ernst gemeint) die sich über Dinge die Finger wund tippen die auf völlig unterschiedlich Nutzer/Nutzung zugeschnitten sind. Neben diversen durchaus intereesanten Sachen list man in jedem dritten Beitrag "ja aber doch nur weil dein System darauf zugeschnitten ist, bei mir ist das aber anders".

Und wenn ich jetzt mal spaßeshalber sage das ich für all die lustigen Spielchen unter Windows nur klicken müsste... <-- ja das ist ein gewollt dämlicher Kommentar aber Windows User sind Masochisten und lassen sich so gerne von den Linuxern zerreißen

Sorry das musste einfach mal sein...

edit:
Oh und ich lese immernoch mit weils ab und an mal interessant ist und das TV Programm noch langweiliger ist. Da ist die Tennis-Diskussion hier doch lustiger und man lernt ja auch was dabei...

 

[c0t0d0s0]

PS: Du gehst in deinem Szenario von einem sequentiellen Ablauf aus. Dann würde das funktionieren. Nur dummerweise darfst du diese Annahme nicht machen, die die Platte intern die Schreibrequest umsortieren kann. Und dadurch können auch trotz Transaktion und CoW Inkonsistenzen entstehen.

Es gibt in ZFS eine Reihe von Vorkehrungen, die dafuer sorgen, das der Ueberblock-Schreibzugriff erst nach der Aenderung der der restlichen Bloecke erfolgt. Aber dazu : Use the source, Luke ... und nun hab ich auch keine Lust mehr ...
.
EDIT :
.

Ich glaube dir auch ja, dass ZFS ein paar Befehle einspaart. Dass es dadurch einfacher wird, ist aber noch lange nicht gesagt. Und schlussendlich (ich wiederhole mich) schränkt es mich zu sehr in meiner Flexibilität ein. Ich will evtl. ein Volume mit ext3 bestücken, zwei weitere sollen mit XFS genutzt werden und möglicherweise doch mal eins mit ReiserFS. EVMS kann das leisten, durch die strikte Trennung von Volume Manager und Filesystem. Bei ZFS habe ich diese Möglichkeit auf Grund der engen Verdrahtung der zwei Subsysteme eben nicht. Ich könnte dann mit mehreren Volume-Managern hantieren. Aber das wird dann erst richtig kompliziert.

Klar geht das ... ufs auf nen zvol ... kein problem ...

 

[Ole]

Ist fast wie Tennis gucken hier...ein ziemlich langer Ballwechsel...
Nur auch beim Tennis wird der spannste Ballwechsel mal langweilig und man freut sich wenn dann doch mal wer den Punkt macht...



Also echt...zwei Leute mit so viel Ahnung (ernst gemeint) die sich über Dinge die Finger wund tippen die auf völlig unterschiedlich Nutzer/Nutzung zugeschnitten sind. Neben diversen durchaus intereesanten Sachen list man in jedem dritten Beitrag "ja aber doch nur weil dein System darauf zugeschnitten ist, bei mir ist das aber anders".

Und wenn ich jetzt mal spaßeshalber sage das ich für all die lustigen Spielchen unter Windows nur klicken müsste... <-- ja das ist ein gewollt dämlicher Kommentar aber Windows User sind Masochisten und lassen sich so gerne von den Linuxern zerreißen

Sorry das musste einfach mal sein...

edit:
Oh und ich lese immernoch mit weils ab und an mal interessant ist und das TV Programm noch langweiliger ist. Da ist die Tennis-Diskussion hier doch lustiger und man lernt ja auch was dabei...

Genau sowas geisterte mir auch durch den Kopf als ich mich durchrang doch noch mal hier rein zu gucken.
Aber ich denke, wir werden hier ziemlich alleine mit den Posts stehen und andere werden sie gar nicht lesen.

Egal, man muss es ja schliesslich nicht lesen. *g*

 

[Onkel Homie]

Jo stimmt schon...aber egal.
Mir war gerade danach.

Das Interessante ist halt: Je mehr Ahung jemand hat, je mehr kommt dann auch so eine gewisse "Fanboy Klamotte" durch. Eigentlich sehr schade das die Objektivität dabei immer so leidet aber ich sehe es bei mir selbst im Laden immer...da muss ich mich auch immer enorm zurücknehmen den Kunden nicht mein favorisiertes Produkt anzudrehen

 

[PuckPoltergeist]

Es gibt in ZFS eine Reihe von Vorkehrungen, die dafuer sorgen, das der Ueberblock-Schreibzugriff erst nach der Aenderung der der restlichen Bloecke erfolgt. Aber dazu : Use the source, Luke ... und nun hab ich auch keine Lust mehr ...

Das geht nicht, wenn du nicht weißt, wann die restlichen Blöcke definitiv geschrieben wurden.
Ein Beispiel:
Du veränderst eine Datei und setzt den Schreibauftrag ab. Das Dateisystem nimmt die Veränderungen vor, mittels CoW, und setzt die Schreibbefehle ans Device ab. Das Device nimmt diese Befehle an. Danach wird der Überblock geändert, um auf die neuen Daten zu zeigen. Das Device nimmt auch diese Schreibbefehle an. Bis jetzt befinden sich die Änderungen aber alle nur im Cache des Devices, wovon das FS nichts weiß. Es veranlasst nun das Löschen der alten Daten, im Glauben, die Modifikationen sind auf der Platte vorgenommen. Auf Grund interner Umsortierungen der Schreib-/Lesekopfbewegungen fängt die Platte nun aber an, die alten Daten zu löschen bevor die neuen Daten (vollständig) geschrieben wurden und/oder bevor der Überblock auf den Plattern modifiziert wurde. In dem Moment stürzt das System ab. Jetzt hast du garantiert Datenkorruptionen. Die neuen Daten wurden noch nicht vollständig geschrieben, aber die alten schon angefangen zu löschen. Das kannst du nur verhindern, wenn du wirklich genau weißt, wann welcher Auftrag durch das Device durch ist, und damit permanent wurde. So lange du keine Rückmeldung der einzelnen Aufträge bis zum Ende hast, kannst du das nicht verhindern.

Klar geht das ... ufs auf nen zvol ... kein problem ...

Ok, dann ist der Volume Manager nicht annähernd so eng mit dem FS verheiratet, wie ich dachte. Wenn das System flexibel genug ist, um verschiedene Dateisysteme zu unterstützen, ist es ja genau das, was ich will. In dem Fall wäre es nur eine andere (konsequentere?) Umsetzung des EVMS. Damit gehört der Volume Manager ja auch nicht zum FS, so wie generell gesagt wird.

PS: Und in dem Fall muss ich natürlich auch meine Kritik bzgl. des ZFS-Designs zurück nehmen. Es kam für mich bis jetzt immer nur so rüber, als wäre VM und FS eine feste Einheit, die nicht zu trennen wäre.

 

[Ole]

Jo stimmt schon...aber egal.
Mir war gerade danach.

Das Interessante ist halt: Je mehr Ahung jemand hat, je mehr kommt dann auch so eine gewisse "Fanboy Klamotte" durch. Eigentlich sehr schade das die Objektivität dabei immer so leidet aber ich sehe es bei mir selbst im Laden immer...da muss ich mich auch immer enorm zurücknehmen den Kunden nicht mein favorisiertes Produkt anzudrehen

Apropos Laden: Steht eigentlich BOINC auf der Liste der vorinstallierten Software?

PS: Ich lass deb Thread jetzt in Ruhe, sonst gibbet noch Mecker vom Scheffe.

 

[Onkel Homie]

hab Cheffe gefragt aber ich durfte nich

 

[PuckPoltergeist]

hab Cheffe gefragt aber ich durfte nich

ROFL, am besten so konfiguriert, dass es für den eigenen Account oder zumindest für den blauen, äh grünen Planeten crunsht.

 

[Onkel Homie]

Klaro wie denn sonst *g*

 

[MassiveBlue]

Guten Abend!

Dieser Thread hat mich doch tatsächlich dazu bewegt hier mal wieder etwas zu schreiben.
Ich habe alle 8 Seiten gelesen und durch die öffentliche Diskussion einiger Experten über Betriebssysteme, ihre Varianten und Dateisysteme viele Hintergrundinformationen und Erfahrungen mitnehmen können.

Vielen Dank für diese offen geführte Diskussion.

 

[foenfrisur]

Danke für Eure ausführlichen Darlegungen.
Hoffendlich haben Eure Frauen auch dafür Verständnis und legen nicht die Beziehung aufs "Trockendock"....
Meine Frau hat für diese ( ihr Wortlaut ) technische " Spielereien" wenig Verständnis und findet andere Sachen wesendlich wichtiger...... ( Schuhe kaufen u.a.)

also wenn ich das so lese....
ich könnte schwören, das das meine frau ist


mfg

 

[horst_sergio]

Ein paar Anmerkungen:

- Kleine Korrektur: Im Artikel steht "Muse" (mit weichem s), gemeint sein dürfte Muße.

- Debian Testing ist uneingeschränkt für Produktionsserver einsetzbar. Stable war zumindest in der Vergangenheit viel zu veraltet. Paketfehler in Testing sind äußerst selten, und wenn doch mal einer auftritt, kann man ihn manuell beheben. Die Software selbst ist bei Testing mehr als bewährt genug.

- Die Solaris-Filesysteme habe ich noch nie eingesetzt, aber habt ihr daran gedacht, das ext3 ohne atime zu mounten beim Geschwindigkeitstest?

- Gewisse Kollegen von mir würden sagen: da sieht man es wieder, x86 ist halt Schrott und untauglich für Solaris .

 

[PuckPoltergeist]

- Debian Testing ist uneingeschränkt für Produktionsserver einsetzbar. Stable war zumindest in der Vergangenheit viel zu veraltet. Paketfehler in Testing sind äußerst selten, und wenn doch mal einer auftritt, kann man ihn manuell beheben. Die Software selbst ist bei Testing mehr als bewährt genug.

Und wie zuverlässig sind Sicherheitsupdates für testing? Ich wäre mit solchen Behauptungen verdammt vorsichtig. Erst recht, wenn stable teilweise dort mit Leuten zu kämpfen hat.

 

[Mogul]

Gewisse Kollegen von mir würden sagen: da sieht man es wieder, x86 ist halt Schrott und untauglich für Solaris

Das können sie nicht sagen da kein sauberes System am Start war. Meines Wissens nach laufen unsere X86 Systeme die von SUN kommen eben doch ziemlich gut. Der prinzipielle Unterschied ist die Tatsache das die Hardware von SUN supportet ist und das die Kunden meist über die Verträge zu den Patchen verfügen. Ein instabiles und unsauberes System wird mir auch unter Sparc dauernd um die Ohren fliegen wenn ich Pech habe. Ich bekomme über den Support dann mitgeteilt das diese und jene Patche mal ausgetauscht werden sollten um Knieschüße aus diesem Bereich zu vermeiden, parallel dazu werden dumps eingeschickt und ausgewertet.

MFG

 

[Riddler82]

Was meinst du mit "unsauberes System" ?
Klingt irgendwie nicht nett.

 

[Opteron]

Was meinst du mit "unsauberes System" ?
Klingt irgendwie nicht nett.

Ich denke mal hardware, die nicht von Sun kommt
Hab ich eigentlich auch Verständnis dafür. Es gibt nunmal zig verschiedene Hardwarekombinationen. Wenn dann mal was bei einem zusammengewürfelten (ja ich weiss, klingt auch nicht nett) Server, wie bei P3D nicht läuft, dann war es halt "Pech", aber 1000% Sicherheit dass ein OS auf / mit jeder Hardware läuft kann keiner geben.

Profis werden aus dem Grund eben gleich die Sun Hardware mitkaufen, quasi alles aus einer Hand. [Exkurs: War / Ist ja ähnlich bei AMD CPUs und AMD Chipsätzen]
Wenn die Sun Server (egal ob x86 oder Sparc) da dann auch Fehler produzieren würden, dann wäre Sun schon längst bankrott ^^

Bei Linux ist halt der Vorteil, dass da viele Leute (mit total unterschiedlicher hardware) umsonst am System schrauben. Das läuft stabil, aber wie man ja anscheinend an den P3D Server load Werten sieht, gäbe es bessere Lösungen.

ciao

Alex

P.S: Mogul könnte vielleicht auch "underpatched" meinen ^^

 

[Mogul]

Nein nein, das hat was mit Patchen und so zu tun, also wenn SUN aus irgendwelchen Gründen Patches zurückzieht und dergleichen. Solche Patches sollten nicht aktiv im system sein.

MFG

 

[Opteron]

Nein nein, das hat was mit Patchen und so zu tun, also wenn SUN aus irgendwelchen Gründen Patches zurückzieht und dergleichen. Solche Patches sollten nicht aktiv im system sein.

Ah ok, sorry, wieder was gelernt

Danke

Alex

 

[c0t0d0s0]

Ah ok, sorry, wieder was gelernt

Underpatched ist auch noch was anderes ... underpatched ist, wenn Patches garnicht eingespielt werden ...

Es gibt ja immer noch da draussen die Meinung, never patch a running system. Aber das ist schlicht falsch .... irgendwann werden die Abhängigkeitsbäume bei einem Patch den man dann doch benoetigt, so lang, das das Patchen dann richtig lange dauert ...

 

[ghostadmin]

Ich hab hier nen Novell 4.11 Server stehen der unser Warenwirtschaftssystem zur Verfügung stellt, der läuft jetzt seit ich ihn von meinem Vorgänger übernommen habe fast ohne Probleme (~1,5 Jahre). Ab und an mal ein purge und dann gehts weiter. Natürlich nutzen wir noch schön IPX/SPX und ich werd daran auch nix ändern so lange es läuft
Wenn das Boot mal wieder schwankt könnt ihr den haben !

Ist wie alt? 15 Jahre? DOS war auch stabil
Bei Netware 6.5 kannste froh sein wenn das Ding eine Woche stabil läuft

 

[Tom24]

Heute wurde ZFS in FreeBSD-CURRENT commited.

http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/026922.html

Das waer ne Moeglichkeit, allerdings mit Arbeit, die sich keiner machen will, verbunden.

 

[Markus Everson]

Profis werden aus dem Grund eben gleich die Sun Hardware mitkaufen, quasi alles aus einer Hand. [Exkurs: War / Ist ja ähnlich bei AMD CPUs und AMD Chipsätzen]
Wenn die Sun Server (egal ob x86 oder Sparc) da dann auch Fehler produzieren würden, dann wäre Sun schon längst bankrott ^^

AFAIR: Es gab einen FP-Bug im US III und IV der nur unter bestimmten Bedingungen auftrat und auf den Sun mit einem Testprogramm reagiert hat das regelmäßig ein paar Rechenoperationen ausgeführt und das Ergebnis mit dem Sollwert verglichen hat.
Die ersten US IV wurden mit einem dicken Bug ausgeliefert der nur durch einen Patch umgangen werden konnte der aber wiederum die FP-Leistung in den Keller trieb.

AFAIK: Sun ist bisher _nicht_ pleite gegangen.

Folgerung1: IBM und HP kochen auch nur mit Wasser. Intel sowieso.

Folgerung2: Suns Chipsätze dürften ebenso wie die Prozessoren Fehler enthalten. Chipsatz, CPU und OS aus einem Haus zu beziehen dürfte hier ein Vorteil sein.

 

[Gast29012019_2]

Hätte man es voher so belassen wie es mal war, hätte mit Sicherheit wohl das SATA-Raid mit dem Sil auch perfekt funkioniert, aber das kann man ja leider vorher nicht wissen. Und dann später die Erkenntnis das Solaris doch nicht das gelbe vom Ei ist schon verdammt bitter.

Aber jetzt läuft ja wie es soll, und mit etwas Glück könnte Ihr den Server jetzt röddeln lassen.

 

[Mogul]

Dazu fällt mir ein das ich heute am Boot200 gearbeitet habe
Nicht nur die Admins hier müssen ab und an am WE raus...nur das die Jungs das hier freiwillig machen. Hoffe es ist nicht so tragisch das ich den Thread mal kapere

Vermutlich könnte man auf einem Systembord + ein IO Bord das Boor noch 3-4 Jahre halten *Angebermodus off*

Vorher (die andere Seite sieht genau so aus)


ohne Kabel


8 Systembords + die sogenannten expander sind ausgebaut.


ein systembord. 4x1200Mhz und 32 oder 64Gig RAM (weiß gerade nicht welche Größe die haben)


genug Speicher (16x interleave)


ein Lüftereinschub von 8ten


Zum schluß halt wieder zusammen bauen udn fertig ist die Laube



...und wer auch mal lächeln will sollte sich mal den Vortrag von Jörg (c0t0d0s0) auf der Bloggerkonf anschauen. Find die gut gemacht, nicht nur weil es ein Kollege ist.

http://www.c0t0d0s0.org/archives/30...nansichten-eines-firmenweiten-Phaenomens.html