Newsgroup: it.comp.os.linux.sys
Titolo: Consiglio per mail server

Ciao a tutti, dovrei implementare un mail server con
postfix + openldap + courier.
Considerando che ho intenzione di far lavorare gli utenti in imap e come
formato posta pensavo si usare le maildir ho un dubbio sul tipo di fs da
utilizzare (ext3, reisefs, ecc.). Voi cosa mi consigliate?
Grazie.

 reiserfs.
Si`, e` di moda, ma se i files non sono di decine, massimo poche 
centinaia di bytes (non KB, ma proprio bytes) che io sappia non ci sono 
vantaggi prestazionali.
Questo almeno circa un anno fa quando avevo cercato info a riguardo. 
Adesso puo` anche darsi che le cose siano cambiate, ma se non lo sono e 
non ci sono evidenze contrarie direi che prestazionalmente uno vale 
l'altro e son buoni entrambi e quindi potrebbe basare la scelta su altri 
criteri (del tipo strumenti di supporto, amministrazione, tuning e 
recovery dell'uno e dell'altro, caratteristiche di supporto di acl 
estese e/o comportamento con le quota e che altro ne so).
Andrea

 utilizzare (ext3, reisefs, ecc.). Voi cosa mi consigliate?
Beh.
Le informazioni che dai sono estremamente insufficienti.
Maildir o mailbox è un parametro fondamentale per la scelta.
Il numero di caselle pure.
La dimensione media altrattanto (la gente popperà o lascerà la posta sul
server, consultandola con IMAP? Ci saranno delle quote??)
In ogni modo... io escluderei reiser perchhè mi sta atavicamente sui
maroni; esistono molti altri FS migliori (chissà se reiser4 in sviluppo ora
sarà retrocompatibile... ho i miei dubbi).
Se hai tante caselle e tanto spazio occupato, allora ti conviene usare uno
storage esterno (tante tante caselle) e qui il discorso cambia.
In ogni altro caso, per esperienza personale, per imap come vuoi usare tu
ext3 va benissimo, è stabile e non da problemi ed è lo standard.
Piuttosto.. vuoi prestazioni molto buone??
usa un server imap ottimo (Dovecot) che con imap rulezza.
Max

 
http://www.decisionsoft.com/pdw/mailbench.html
e` assolutamente d'accordo con te, ma e` di circa 3 anni fa e nel 
frattempo credo che prestazionalmente ext3 sia migliorato parecchio.
http://lists.debian.org/debian-user-french/2003/09/msg00343.html
di poco piu` di un anno fa non e` cosi` d'accordo, soprattutto in 
lettura, dove parrebbe far meglio ext3.
Comunque non sembra tanto facile trovare dei benchmark recenti con 
kernel 2.6.x per imap e maildir o anche semplicemente per i filesystem 
in questione (o almeno con google questa sera non lo e`).
Ripeto che i grossi vantaggi prestazionali di reiserfs erano con files 
di decine di bytes o poche centinaia (quindi decisamente < di quelli di 
normali messaggi di e-mail).
Andrea

 l'opzione giusta forse avrei recuperato tutto tutto).
Ops.. un'altra esperienza comune :)
Confermo le doti positive nel recupero di reiserfs....
Ormai e' abbastanza consolidato ed e' saldo come una roccia....
Saluti.
--
Giuseppe Careri

 Maildir o mailbox è un parametro fondamentale per la scelta.
Veramente questo lo ha detto due volte: implicitamente, quando
ha parlato di courier, ed esplicitamente qualche riga dopo :-)
Nondimeno, non fornisce certo tante info.
Comunque il problema principale con maildir, enfatizzato dall'
uso di imap (e courier) e' il potenziale grande numero di file
in ogni cartella. Da questo punto di vista ext3, storicamente,
non eccelle di certo. Con la introduzione della indicizzazione
delle directory, pero', si comporta piuttosto bene, a patto di
avere il supporto compilato nel kernel e abilitato.
Fabio

 avere il supporto compilato nel kernel e abilitato.
Vero, parametrizzato però in base al server imap che usi.
Se ne usi uno evoluto, con caching e indicizzazione delle directory (come
dovecot, ad esempio) non hai sicuramente alcun problema, a prescindere
dalle abilitazioni del kernel.
Esiste, inoltre, un oggettino che si chiama "imapproxy" che serve a ridurre
ulteriormente alcuni overhead.
Max

 ulteriormente alcuni overhead.
Non l'ho mai usato, gli daro' un'occhiata.
Fabio

 sono sufficienti.
Si ma concorderai anche che i confronti tra ext3,XFS,NFS,CODA,ReiserX e chi
ne ha più ne metta sono test comparativi ESTREMI.
Ovvero calcolati stressando la macchina a più non posso.
Se hai un server che ti fa da imap e che è stressato, o è un P2 di 10 anni
fa oppure hai un sistema sottodimensionato con un doppio zeon e 50mila
mailbox con grado di contemporaneità del 50% e dischi ATA a 4200 giri...
Io sono sempre restio a dare fede ai benchmark dei FS.
Capisco che uno preferisca (ad esempio) XFS ad ext2, visto che il primo è
journaling e il secondo no (differenza generazionale).
Per il resto, per un +/- 5% di prestazioni sotto carico estremo preferisco
dimensionare bene le macchine e usare il File system che mi può dare meno
problemi.
In questa ottica, ext3 non mi ha mai dato problemi ed è sempre stato
ultra-performante. Odio Reiser che tra una versione e l'altra poco se ne
cale della retrocompatibilità...
Max

 la introduzione
Hai barato! ;-P
-- 
Il 12 giugno scegli se vuoi uno stato liberale
od uno stato (pseudo)etico: vota sì ai referendum.

 Hai barato! ;-P
Edddddai... nei limiti sia del lecito, sia della lingua italiana :-P
E poi ero di fretta. 
Tie'...
<< non eccelle certamente. Con l'introduzione dell'indicizzazione >>
Fab

 vantaggi prestazionali.
falso. xfs e reiser sono algoritmicamente migliori di ext3. Quest'ultimo
e' fatto a liste, quando avrai tanti file sara' molto lento, gli altri
terranno meglio, perche' sono fatti ad alberi.


La teoria e` una gran bella cosa, pero` a volte anche la pratica, se si 
gestiscono sistemi reali e non teorici, puo` avere il suo peso. Hai 
benchmark di casi d'uso reali e con kernel e filesystem abbastanza 
recenti che dimostrino quanto sostieni? Anche perche' "tanti files" 
potrebbe essere 1.000.000 in una directory come 10.000. Solo che se e` 
un milione, direi che nel 99,99 % dei casi te ne puoi fregare; come 
anche per i files; continuavo a sentir dire e leggere che reiserfs era 
piu` veloce con tanti files piccoli e allora uno si immagina file di 
pochi KB e poi invece scopre che non e` vero, ma benchmark reali 
dimostrano che e` vero per files di decine di bytes o al massimo di 100 
o 200; bestie non cosi` comuni nella realta`, anche se solidamente 
attestate nella teoria o in casi reali estremamente improbabili.
L'unico vantaggio, che sembra fosse reale fino a poco meno di 2 anni fa 
(adesso non so se sia piu` cosi`) e` che reiserfs gestiva meglio I-nodes 
e spazio su disco, per cui non ti esauriva i primi e su partizioni 
grandi (ordine di 100 GB) con files relativamente piccoli ( < 10 KB) 
consumava un 15-20% di spazio in meno di ext3.
Andrea

 recenti che dimostrino quanto sostieni?
Bah, ti posso dire la mia di qualche tempo fa...
Partizione dedicata a /var/spool/mail, contenente maildir di circa 6000 
utenti, organizzate su due livelli di hash.
La macchina iniziava a fare fatica nell'I/O verso la partizione. Passata 
a reiserfs ha avuto un 20% di margine. Tutta la differenza che passa tra 
un servizio che funziona e un helpdesk incasinato.
Quella sul nuovo HW l'ho fatta direttamente su reiserfs...
-- 
Здрасти!
cat: .signature: No such file or directory


Grazie, adesso so perche' stai usando reiserfs :-)
Anch'io lo uso (invece di ext3), nonostante non avessi buone ragioni 
teoriche o pratiche per farlo. Le prime per mancanza di conoscenza, le 
seconde per mancanza di conoscenza (non sono riuscito a trovare 
benchmark) e anche perche' nella maggior parte delle situazioni, meno 
impegnative di quella che descrivi, credo che la differenza non sia 
significativa nel senso "che passa tra un servizio che funziona e un 
helpdesk incasinato".
Pero` a questo punto, se riesci ancora a recuperare i dati, vorrei 
andare fino in fondo, perche', come ben si sa, il diavolo si cela nei 
particolari. Quale kernel? Quale versione di ext3 e reiserfs? E 
soprattutto, con quali parametri sono stati creati i file system?
Andrea

Dimenticavo ancora l'ultima domanda importante e cioe` con quali opzioni 
venivano montati i file system.
Andrea

 venivano montati i file system.
Trattavasi, all'epoca, di una RH9 con kernel 2.4 (.ventiqualcheccosa)
ext3 montanto con opzioni nodev,nosuid,noexec,noatime
reiserfs3.6 con le stesse opzioni + notail.


 reiserfs3.6 con le stesse opzioni + notail.
Grazie.
La creazione dei fs e` avvenuta con le opzioni di default? (ovvero senza 
specificarne di particolari)
Andrea

 
Provato diverse "versioni" (soprattutto su reiserfs, provato con 
algoritmi di hash diversi), ma le variazioni sono state non percepibili, 
almeno sulla scala che esaminavo (non dubito che bench adeguati portino 
ad apprezzare le differenze "di fino").
Una cosa che ho notato, anche se non è un dato significativo preso di 
per sè, è l'enorme differenza di pesantezza computazionale tra i kernel 
thread che si occupano del journaling (kreiserfsd vs. kjournald).
kjournald impegna la CPU (a parità di I/O) in misura superiore di 
parecchi ordini di grandezza rispetto a kreiserfsd (o a xfsbufd + 
xfssyncd, quanto a quello...).
La cosa di per sè credo sia poco rilevante (la CPU difficilmente diviene 
il collo di bottiglia) ma potrebbe (con le molle, non sono un 
programmatore) essere indice di una inadeguatezza della struttura del 
filesystem rispetto al layout sicuramente più moderno degli altri FS...


 reiserfs3.6 con le stesse opzioni + notail.
Notail consigliato solo per il root filesystem se non sbaglio. 


Dovrebbe essere solo per /boot in modo che il kernel non venga mai
toccato.
Gufo
-- 
  ,___,		| 	  alt.sex.disney 
  (9v9)		|   Mickey, Minney --- you know. 
  (_^((\	|
-^-"-"-\\-^--	| Remove -me- to reply in email

 toccato.
Non c'e' male come mio primo post, ho scritto una cazzata.
Notail in /boot si mette per non confondere lilo, non per non toccare
il kernel, era una mia convinzione sbagliata.
Notail si usa anche per incrementare le performance di scrittura su
disco, che in cambio delle performance ci sia un minimo spreco di spazio.
http://www-106.ibm.com/developerworks/linux/library/l-fs2.html


 
http://www-106.ibm.com/developerworks/linux/library/l-fs2.html
Esattamente...
