Re: Re: Geeignetes Fiesystem für Datenbankpartition gesucht

Hallo Liste,
Wir richten uns hier gerade einen dezidierten DB-Server ein. Auf
diesem System sollen vorerst 2 Datenbanken mit einer Größe
(perspektivisch gesehen) im einstelligen Gigabytebereich laufen.

Zur Partitionierung:
- Hardwareraid
-> Raid5 über drei Platten für System, Logs etc
-> Raid1 über 2 Platten für Datenbankdaten

Nun bräuchte ich eine "Entscheidungshilfe", für welches Dateisystem
wir uns entscheiden sollen. Ich persönlich schwanke ja zwischen ext3
und XFS mit Hang zu XFS. Genügend Speichern (16G) und eine redundante
Stromversorgung sind gegeben.

Viele Grüße aus Dresden
Robert

Robert Müller schrieb:

> Nun bräuchte ich eine "Entscheidungshilfe", für welches Dateisystem
> wir uns entscheiden sollen. Ich persönlich schwanke ja zwischen ext3
> und XFS mit Hang zu XFS. Genügend Speichern (16G) und eine redundante
> Stromversorgung sind gegeben.

XFS hat meines Wissens weder geschwindigkeitsmässig noch Featuremässig
Vorteile, nur eine deutlich komplexere und weniger intensiv getestete
Codebasis. [1]

Wenn die Workload bzw. Geschwindigkeit unproblematisch ist, ext3, wenns
flotter sein muss, ext2 (ist kolportierterweise nicht so sicher (im
Sinne von "truncated writes trotz returntem fsync") wie ext3).

Und bzgl. redundanter Stromversorgung: entweder du hast einen Battery
Backed Write-Cache, dann darfst du den Write Cache des Controllers
aufdrehen, oder du hast keinen BBWC, dann bleibt der Write Cache des
Controllers abgedreht. Write Cache auf den Platten _immer_ deaktivieren.

"Vendor-Controller" (HP SmartArray zumindest) machen das alles
automatisch für dich, damit du nicht mit heruntergelassenen Hosen
erwischt wirst, bei allen anderen Herstellern, besonders am
Third-Party-Vendor Sektor musst das händisch machen oder im Zweifelsfall
mit gallopierenden Datenfraß (je nach FS, Größe des Buffers, etc.) rechnen.

lg,
Michael

[1] auch für XFS relevant:
http://linuxmafia.com/faq/Filesystems/reiserfs.html

Leider hab ich mir die ganzen XFS-FUD-Artikel nicht gebookmarkt ;).

--

Michael Renner
InQnet GmbH
Praterstraße 31
A-1020 Wien

Tel.: +43 1 212 7650 521
Fax.: +43 1 212 7650 610

am Mon, dem 25.02.2008, um 15:06:30 +0100 mailte Robert Müller folgendes:
> Hallo Liste,
> Wir richten uns hier gerade einen dezidierten DB-Server ein. Auf
> diesem System sollen vorerst 2 Datenbanken mit einer Größe
> (perspektivisch gesehen) im einstelligen Gigabytebereich laufen.
>
> Zur Partitionierung:
> - Hardwareraid
> -> Raid5 über drei Platten für System, Logs etc
> -> Raid1 über 2 Platten für Datenbankdaten
>
> Nun bräuchte ich eine "Entscheidungshilfe", für welches Dateisystem
> wir uns entscheiden sollen. Ich persönlich schwanke ja zwischen ext3
> und XFS mit Hang zu XFS. Genügend Speichern (16G) und eine redundante

Vielleicht das, was ihr besser kennt. Negatives hört man weder von ext3
noch von xfs. Ansonsten halte ich den Einfluß des FS auf die Performance
für eher nebensächlich. Aber wenn Du schon 2 RAIDs hast, warum dann
alles für die DB auf ein und dasselbe legen? Vermutlich könntest Du echt
gewinnen, wenn Du das Transaction Log z.B. auf eine andere Spindel legst,
und/oder die Indexe.

Andreas, bis bald zum CLT *g*
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--On Montag, Februar 25, 2008 16:01:51 +0100 "A. Kretschmer"
<andreas(dot)kretschmer(at)schollglas(dot)com> wrote:

> Vielleicht das, was ihr besser kennt. Negatives hört man weder von ext3
> noch von xfs.

Außer das XFS den Hang verspürt, Dateien, in die im Moment eines Crashes
geschrieben wird mit Nullbytes zu verschönern [1]. Häufig zitiertes
"Problem" und selbst mit neueren Kerneln <= 2.6.22 anzutreffen. Das ist
ein XFS _Feature_, und PostgreSQL sollte relativ immun dagegen sein, es gab
aber in der Vergangenheit genug Probleme damit.

Ferner hört man ab und an, dass die XFS-Performance hinsichtlich fsync()
nicht immer die Beste sein soll, da hier einfach viel mehr Schreibaufwand
nötig ist (gilt aber eigentlich für fast alle Journaling-FS).

[1] <http://oss.sgi.com/projects/xfs/faq.html#nulls>

--
Thanks

Bernd

Moin,

Michael Renner wrote:

> http://linuxmafia.com/faq/Filesystems/reiserfs.html
>
> Leider hab ich mir die ganzen XFS-FUD-Artikel nicht gebookmarkt ;).

Ja, FUD ist hier tatsaechlich die treffende Bezeichnung. Ich hab'
diesen Test, dass man dem Rechner den Strom genau dann klaut, wenn's am
lustigsten ist, selber haeufig, auf verschiedenen Rechnern, mit
verschiedenen 'Nutzlasten' auf XFS gemacht. Verluste konnte ich dabei
nicht feststellen, solange nicht ohnehin irgendein Festplatten- oder
Kabel-Defekt vorlag. Daran kann dann auch das dollste Filesystem
natuerlich nichts aendern.
Letztens hatte ich mal nach einem vollkommen sauberen Reboot eines
Systems mit 'ner Sybase-Datenbank auf Ext3 mit Default-Parametern den
Effekt, dass manche Dateien ploetzlich dem 'root' gehoerten und nicht
mehr dem 'sybase' und die Datenbank deshalb nicht anlief ....

Fazit: Fragst Du drei Leute, bekommst Du meist vier Antworten. Mach'
einfach eine kleine Testreihe mit der Hardware, auf der Du das spaeter
laufen lassen willst, und dann weisst Du, woran Du bist.

Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Martin Spott schrieb:

> Ja, FUD ist hier tatsaechlich die treffende Bezeichnung.

[..]

> Fazit: Fragst Du drei Leute, bekommst Du meist vier Antworten. Mach'
> einfach eine kleine Testreihe mit der Hardware, auf der Du das spaeter
> laufen lassen willst, und dann weisst Du, woran Du bist.

Oder man schaut sich einfach an, was die Dateisysteme unter der Haube
machen und schließt von da weg auf mögliche Fehlerszenarien. Sei's Lines
of code, Komplexität/Robustheit der On-Disk-representation oder
generelle Qualität der Implementation. Auf dieser Basis kann man
ziemlich bequem und ohne viel herumgezetere sinnvolle Entscheidungen
treffen, ohne dass man mit flammenden Schwert gegen andersdenkende
vorgehen muss (und ich bin der erste der auf ext3 verzichtet wenn etwas
sinnvolleres daherkommt).

Weitere Diskussionen zu diesem Thema am besten abseits der Mailingliste
bei einem Bier, oder hier auf der Liste mit Fakten ("Was passiert wenn
ein Write truncated wird? Was explodiert alles wenn ein Bit/Byte/Block
durch Memory/CPU/kaputte Controller/Power Loss/Cosmic Rays
geflippt/gezappt/durchgenudelt wird?". Ich bin diese "ich habe
gehört/gesehen/gelesen, dass" Argumentationslinien satt)

Quintessenz: Fehler haben Ursachen. Diese Ursachen sind immer
deterministisch in der Definition, nicht im Auftreten. Jedes FS verhält
sich bei unterschiedlichen Fehlerquellen anders. Ein FS das "am Papier"
gut ist, bei dem "die Realität" aber kein Design Target war, ist
vermutlich kein gutes FS für Produktionssysteme.

Und zu deinem mysteriösen Permission-Flip am Produktionssystem: Wenns
dich _wirklich_ interessiert, frag auf der ext3-users Mailingliste
welche Code-Paths das ausgelöst haben könnten. Ich persönlich vermute
mal kaputte Startup/Shutdown-Scripts bzw. DB-Implementation oder ein
nicht zuende durchgespieltes Journal (Metadaten-Änderungen nicht korrekt
zu Ende durchgeführt). Das bei "mehreren" Dateien die selben Bits immer
auf den gleichen Wert "korrumpiert" werden ist denkbar unwahrscheinlich.

my 2 cents..

over'n'out,
Michael

P.s. Food for thought:
http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent_Corruptions.pdf

Danke für die Interessanten Emails.

Wir haben uns erstmal entschieden bei reiserfs zu bleiben (never touch
a running System) weil wir damit bisher nie schlechte Erfahrungen
hatten.

@ Andreas: Wir reden auf dem Linuxtag noch mal über die optimale
Aufteilung der DBDaten. Ausserdem erhoffe ich mir vom Workshop
"PostgreSQL Hardcore Performance Tuning" jede Menge neues Wissen.

Schöne Grüße
Robert

am Thu, dem 28.02.2008, um 12:44:45 +0100 mailte Robert Müller folgendes:
> Danke für die Interessanten Emails.
>
> Wir haben uns erstmal entschieden bei reiserfs zu bleiben (never touch
> a running System) weil wir damit bisher nie schlechte Erfahrungen
> hatten.

Ich hätte den Satz, wonach man weder von ext3 noch von xfs negatives
hört, wohl doch ergänzen sollen um, sagen wir mal: ", wohl aber von
reiserfs".

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--On Donnerstag, Februar 28, 2008 12:54:06 +0100 "A. Kretschmer"
<andreas(dot)kretschmer(at)schollglas(dot)com> wrote:

> Ich hätte den Satz, wonach man weder von ext3 noch von xfs negatives
> hört, wohl doch ergänzen sollen um, sagen wir mal: ", wohl aber von
> reiserfs".

Das meiste davon bezieht sich auf die 3.5er Versionen und ist Asbach-Uralt,
wie man so schön sagt. Die 3.6er Versionen können schon als ziemlich
ausgereift angesehen werden. Bei ReiserFS steht wohl eher die ungewisse
Zukunft negativ gegenüber.

--
Thanks

Bernd