SGFsbG8gTGlzdGUsCldpciByaWNodGVuIHVucyBoaWVyIGdlcmFkZSBlaW5l
biBkZXppZGllcnRlbiBEQi1TZXJ2ZXIgZWluLiBBdWYKZGllc2VtIFN5c3Rl
bSBzb2xsZW4gdm9yZXJzdCAyIERhdGVuYmFua2VuIG1pdCBlaW5lciBHcsO2
w59lCihwZXJzcGVrdGl2aXNjaCBnZXNlaGVuKSBpbSBlaW5zdGVsbGlnZW4g
R2lnYWJ5dGViZXJlaWNoIGxhdWZlbi4KClp1ciBQYXJ0aXRpb25pZXJ1bmc6
Ci0gSGFyZHdhcmVyYWlkCiAgICAtPiBSYWlkNSDDvGJlciBkcmVpIFBsYXR0
ZW4gZsO8ciBTeXN0ZW0sIExvZ3MgZXRjCiAgICAtPiBSYWlkMSDDvGJlciAy
IFBsYXR0ZW4gZsO8ciBEYXRlbmJhbmtkYXRlbgoKTnVuIGJyw6R1Y2h0ZSBp
Y2ggZWluZSAiRW50c2NoZWlkdW5nc2hpbGZlIiwgZsO8ciB3ZWxjaGVzIERh
dGVpc3lzdGVtCndpciB1bnMgZW50c2NoZWlkZW4gc29sbGVuLiBJY2ggcGVy
c8O2bmxpY2ggc2Nod2Fua2UgamEgendpc2NoZW4gZXh0Mwp1bmQgWEZTIG1p
dCBIYW5nIHp1IFhGUy4gR2Vuw7xnZW5kIFNwZWljaGVybiAoMTZHKSB1bmQg
ZWluZSByZWR1bmRhbnRlClN0cm9tdmVyc29yZ3VuZyBzaW5kIGdlZ2ViZW4u
CgpWaWVsZSBHcsO8w59lIGF1cyBEcmVzZGVuClJvYmVydAoKLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKGVuZCBvZiBicm9hZGNhc3QpLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tClRJUCAzOiBIYXZlIHlvdSBjaGVja2VkIG91
ciBleHRlbnNpdmUgRkFRPwoKICAgICAgICAgICAgICAgaHR0cDovL3d3dy5w
b3N0Z3Jlc3FsLm9yZy9kb2NzL2ZhcQo=

Robert M=C3=BCller schrieb:

> Nun br=C3=A4uchte ich eine "Entscheidungshilfe", f=C3=BCr welches Datei=
system
> wir uns entscheiden sollen. Ich pers=C3=B6nlich schwanke ja zwischen ex=
t3
> und XFS mit Hang zu XFS. Gen=C3=BCgend Speichern (16G) und eine redunda=
nte
> Stromversorgung sind gegeben.

XFS hat meines Wissens weder geschwindigkeitsm=C3=A4ssig noch Featurem=C3=
=A4ssig
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=C3=BCr dich, damit du nicht mit heruntergelassenen Hosen
erwischt wirst, bei allen anderen Herstellern, besonders am
Third-Party-Vendor Sektor musst das h=C3=A4ndisch machen oder im Zweifels=
fall
mit gallopierenden Datenfra=C3=9F (je nach FS, Gr=C3=B6=C3=9Fe des Buffer=
s, etc.) rechnen.

lg,
Michael

[1] auch f=C3=BCr 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=C3=9Fe 31
A-1020 Wien

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

am Mon, dem 25.02.2008, um 15:06:30 +0100 mailte Robert Müller folgend=
es:
> 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 Performanc=
e
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 e=
cht
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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

--On Montag, Februar 25, 2008 16:01:51 +0100 "A. Kretschmer"
<andreas.kretschmer [at] schollglas.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 Crashe=
s
geschrieben wird mit Nullbytes zu verschönern [1]. Häufig zitiertes
"Problem" und selbst mit neueren Kerneln <=3D 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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 !
------------------------------------------------------------ --------------

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 Li=
nes
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 vermu=
te
mal kaputte Startup/Shutdown-Scripts bzw. DB-Implementation oder ein
nicht zuende durchgespieltes Journal (Metadaten-=C4nderungen nicht korrek=
t
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-Silen t_Corruptions=
..pdf

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

RGFua2UgZsO8ciBkaWUgSW50ZXJlc3NhbnRlbiBFbWFpbHMuCgpXaXIgaGFi
ZW4gdW5zIGVyc3RtYWwgZW50c2NoaWVkZW4gYmVpIHJlaXNlcmZzIHp1IGJs
ZWliZW4gKG5ldmVyIHRvdWNoCmEgcnVubmluZyBTeXN0ZW0pIHdlaWwgd2ly
IGRhbWl0IGJpc2hlciBuaWUgc2NobGVjaHRlIEVyZmFocnVuZ2VuCmhhdHRl
bi4KCkAgQW5kcmVhczogV2lyIHJlZGVuIGF1ZiBkZW0gTGludXh0YWcgbm9j
aCBtYWwgw7xiZXIgZGllIG9wdGltYWxlCkF1ZnRlaWx1bmcgZGVyIERCRGF0
ZW4uIEF1c3NlcmRlbSBlcmhvZmZlIGljaCBtaXIgdm9tIFdvcmtzaG9wCiJQ
b3N0Z3JlU1FMIEhhcmRjb3JlIFBlcmZvcm1hbmNlIFR1bmluZyIgamVkZSBN
ZW5nZSBuZXVlcyBXaXNzZW4uCgpTY2jDtm5lIEdyw7zDn2UKUm9iZXJ0Cgot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0oZW5kIG9mIGJyb2FkY2FzdCkt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVElQIDM6IEhhdmUgeW91IGNo
ZWNrZWQgb3VyIGV4dGVuc2l2ZSBGQVE/CgogICAgICAgICAgICAgICBodHRw
Oi8vd3d3LnBvc3RncmVzcWwub3JnL2RvY3MvZmFxCg==

am Thu, dem 28.02.2008, um 12:44:45 +0100 mailte Robert Müller folgend=
es:
> 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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

--On Donnerstag, Februar 28, 2008 12:54:06 +0100 "A. Kretschmer"
<andreas.kretschmer [at] schollglas.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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match