[mbox -> maildir :: opnieuw formatteren?}

[usr-local-dick]

Hoi

Ik ben van plan om onze mailserver (debian/uw-imap) om te zetten van mbox naar maildir formaat. Hiervoor is het ook nodig dat de huidige mailboxen van onze gebruikers omgezet worden. Alleen nu vraag ik me af of dat wel kan met mijn huidige filesysteem.
De server heeft een 17 Gb partitie voor /home, hier zit de mail in van de users.
Hoewel er niet veel users zijn hebben ze echt giga mailboxen, soms met honderden subfolders etc etc. Er zijn gebruikers die 200 Mb hebben maar sommige (mijn baas ) hebben bijna 2 Gb.
Omdat bij het omzetten naar maildir ieder mailtje een file wordt zullen er dus heel veel files gebruikt gaan worden (onze medewerkers beware bijna alle mail dus tsja).
Mijn huidige filesysteem (ext3 - dat wil ik liever zo laten) ziet er zo uit:

code:

root@erasmus:/home# tune2fs -l /dev/sda5
tune2fs 1.27 (8-Mar-2002)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ca5e3907-1fb5-4b78-b497-6b455b20115d
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2305632
Block count:              4608639
Reserved block count:     230431
Free blocks:              1120083
Free inodes:              2280639
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16352
Inode blocks per group:   511
Last mount time:          Wed Jun 16 19:18:23 2004
Last write time:          Wed Jun 16 19:18:23 2004
Mount count:              4
Maximum mount count:      27
Last checked:             Sat Feb 14 12:37:06 2004
Check interval:           15552000 (6 months)
Next check after:         Thu Aug 12 13:37:06 2004
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal UUID:             <none>
Journal inode:            8
Journal device:           0x0000
First orphan inode:       0

Als ik het goed bekijk kunnen er dus niet meer dan 2,3 miljoen files op.
Iemand een aanbeveling voor een andere block size, misschien zelfs ervaring met inrichting van maildir partities? Ik neem aan als ik een kleine block size neem dat er dan meer inodes komen?

[Wilke]

Een tip: gebruik reiserfs voor maildir partities.

Waarom?

Zoals je zelf al zegt krijg je dus directories met reusachtige bergen files. De korte samenvatting is dat reiserfs enorm veel efficienter werkt in directories met veel files dan ext3.

De lange uitleg is dat dat komt omdat ext3 de files per directory in een simpele lijst opslaat, wat betekent dat de zoektijd voor een specifieke file lineair toeneemt met het aantal files (dat wordt wel genoteerd als 'de zoektijd is O(n)').

Reiserfs gebruikt een binary tree om de files in de directory te rangschikken, en een binary tree heeft een zoektijd die logaritmisch toeneemt met het aantal files (dat wordt wel genoteerd als 'O(2log(n))').

Even concreet: een directory met 10.000 mails zal geen uitzondering zijn. ext3 moet gemiddeld 5000 files (10k/2) aflopen voor hij de goede heeft gevonden in een bepaalde subdir.

Reiserfs hoeft daarentegen slechts 2log(10k) = 13,3 stappen te nemen om elke willekeurige file in die subdir te vinden.

Zoals altijd: don't take my word for it, maar check bv. eens deze benchmark, waarin mbox, maildir en mbx formaat worden geleken op ext3 en reiserfs (in totaal 6 combinaties dus).

De conclusie kan ik alvast wel verklappen:

Maildir + ReiserFS is a win on pretty much every front, and a significant improvement in several crucial operations (opening a new mailbox and deleting from a mailbox). The only loss is in search speed, and this can be improved by tweaking some FS options (turning off atime updates).

Of je het eens bent met hun benchmark en meetmethoden mag je voor jezelf uitmaken natuurlijk

[usr-local-dick]

Ja dat is een optie. Alleen al onze servers hebben ext3 partities, die worden allemaal gebackuped met dump/restore.
Dat willen we graag zo houden

[blaataaps]

usr-local-dick schreef op 25 augustus 2004 @ 11:34:
Hoi

Ik ben van plan om onze mailserver (debian/uw-imap) om te zetten van mbox naar maildir formaat. Hiervoor is het ook nodig dat de huidige mailboxen van onze gebruikers omgezet worden. Alleen nu vraag ik me af of dat wel kan met mijn huidige filesysteem.
De server heeft een 17 Gb partitie voor /home, hier zit de mail in van de users.
Hoewel er niet veel users zijn hebben ze echt giga mailboxen, soms met honderden subfolders etc etc. Er zijn gebruikers die 200 Mb hebben maar sommige (mijn baas ) hebben bijna 2 Gb.
Omdat bij het omzetten naar maildir ieder mailtje een file wordt zullen er dus heel veel files gebruikt gaan worden (onze medewerkers beware bijna alle mail dus tsja).
Mijn huidige filesysteem (ext3 - dat wil ik liever zo laten) ziet er zo uit:


Als ik het goed bekijk kunnen er dus niet meer dan 2,3 miljoen files op.
Iemand een aanbeveling voor een andere block size, misschien zelfs ervaring met inrichting van maildir partities? Ik neem aan als ik een kleine block size neem dat er dan meer inodes komen?

Nouja, eigenlijk geef je zelf het antwoord al min of meer, het is op zich een simpel rekensommetje, de grootte van die partitie delen door de gemiddelde size van een mailtje, ik neem niet aan dat iedereen elkaar .bmps stuurt, dus die zal niet zo heel groot zijn, maar dat weet jij beter dan ik
Als dat sommetje op meer (of bijna meer) uitkomt dan 2.3miljoen zul je een nieuw filesystem moeten aanmaken, dat is niet achteraf te tunen.
De -T opties van mke2fs lijkt eventueel een goede hulp bij het berekeken van de hoeveelheid inodes:

-T fs-type
Specify how the filesystem is going to be used, so that mke2fs can chose optimal filesystem parameters for that
use. The supported filesystem types are:

news one inode per 4kb block

largefile one inode per megabyte

largefile4 one inode per 4 megabytes

maar je kunt natuurlijk zelf ook aan het rekenen slaan
Zoals wilke ook al aangeeft kun je ook een ander FS overwegen, reiser is niet mijn persoonlijke favoriet, maar die werkt sneller met een hoop kleine files, xfs doet geloof ik ik ook trucjes met binary trees die dat soort operaties versnellen.

[Wilke]

Trouwens, dat 'search speed' op reiserfs trager is, is logisch te verklaren (en niet in strijd met mijn punt dat de zoektijd naar een specifieke file op reiserfs korter is): als je iets in je mail zoekt, ga je alle mails (dus files) bij langs. Als je dat op ext3 slim aanpakt, loop je dus gewoon domweg de hele lijst 1 keer af. Bij reiserfs moet je daarentegen een binary tree aflopen, wat van nature gewoon iets trager is dan een lijst aflopen.

Dat is dus de tradeoff: op reiserfs kun je sneller een specifieke file vinden, maar op ext3 is het aflopen van alle files in een dir ietsje sneller. Je kunt op je klompen wel aanvoelen dat op een mailserver (vooral als het om imap gaat!) het opvragen van een specifieke mail tig maal vaker voorkomt dan het doorzoeken van een hele directory.

Het is zeker een goed plan om die 'noatime,nodiratime' opties ook te testen in jouw setup - mits je wel weet wat het precies doet.


Om tot slot nog maar even echt ontopic te reageren : de standaard inode size is inderdaad 4096, bij ext3 zou je die eventueel nog op 2048 of zelfs 1024 kunnen zetten (ik denk dat 2048 dan het handigst is in jouw setup).

In dit artikel staan daar nog wel wat zinnige dingen over (voor verschillende file systems), een van de commentaren is:

You don't want to change the ReiserFS block size (unless you really know what you're doing). ReiserFS employs a technique called tail packing where the last block of a file is put in another file's slack space, thereby using disk space much more efficiently. As far as I know, no other file system is boasting this (but please correct me if I'm wrong).

De standaard blocksize bij reiserfs is trouwens ook 4096.


Maar goed, als je vast zit aan dump/restore, dan houd het idd op. Overigens vind ik dit dan wel een interessant artikel:

Yes, it's true; ReiserFS does not yet have a "dump" and "restore" implementation. If you want to user ReiserFS and happen to be a "dump" fan, you'll have to find some alternate way of backing data. In reality, this turns out to be a non-issue, since 2.4 kernels are incompatible with "dump" and "restore" in the first place. For more information on the dump/kernel 2.4 incompatibility, read the posting by Linus Torvalds, where he says that "Dump was a stupid program in the first place. Leave it behind."

Jullie draaien dus ook nog volledig op 2.2 kernels (niet dat daar iets mis mee is overigens)?

[Buffy]

Overigens heeft blocksize niks te maken met het aantal inodes behalve dan dat je niet meer inodes dan blocks kan hoeft te hebben

Blocksize bepaalt de interne fragmentatie van de beschikbare ruimte, oftewel de hoeveelheid ongebruikte bytes in de laatste blocken van de bestanden. Als het meerendeel van de bestanden kleiner is dan 1024 bytes dan is het natuurlijk verspilling om een blocksize van 4096 bytes te gebruiken.
Echter als een bestand groter is dan 12 blocks dan worden er weer extra blocks gebruikt om de lijst met block pointers in op te slaan dus als je veel grote bestanden hebt wil je de block size juist groter hebben (en voor hele grote filesystemen geldt waarschijnlijk de 2^32 grens wat betreft aantal blocks).

Het aantal inodes is zoals blaataaps aangeeft afhankelijk van de gemiddelde bestandsgrote. Bij teveel inodes verspil je ruimte door ongebruikte inode blocks (die als data blocks gebruikt hadden kunnen worden) en te weinig inodes is gewoon lullig

Ook een voordeel van ReiserFS is dat het geen (vast aantal) inodes gebruikt en fragmenten compact op slaat.

[usr-local-dick]

Maar goed, als je vast zit aan dump/restore, dan houd het idd op. Overigens vind ik dit dan wel een interessant artikel:
[...]


Jullie draaien dus ook nog volledig op 2.2 kernels (niet dat daar iets mis mee is overigens)?

Nee uiteraard op 2.4 en 2.6 kernels
Dat verhaal van Torvalds heeft een hoop stof doen opwaaien maar hier kun je lezen dat hij uit zijn nek lult

[igmar]

usr-local-dick schreef op 25 augustus 2004 @ 13:25:
Nee uiteraard op 2.4 en 2.6 kernels
Dat verhaal van Torvalds heeft een hoop stof doen opwaaien maar hier kun je lezen dat hij uit zijn nek lult

Ik zou het verhaal dan nog maar eens lezen, vooral het stuk over dat het FS tijdens de dump kan veranderen, en de mogelijke gevolgen.

[Wilke]

Okee..nou ja, als je de nadelen van ext3 voor lief neemt om dump/restore te kunnen blijven gebruiken, dan moet je dat doen natuurlijk. Kan me voorstellen dat je er niet op zit te wachten om de backup-strategie er voor aan te passen.

Zoals blaataaps aangeeft kun je dus bij het maken van een ext2/3-fs wel aangeven hoeveel inodes er moeten komen.