[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Rocco Rutte wrote on Wed, Nov 28, 2007 at 22:26 +0100:
> >> Man kann definieren, dass eine mbox-Mailbox ungelesene Nachrichten
> >> hat, wenn mtime > atime. 
> 
> >Macht das etwa jemand?! Das geht ja schon kaputt, wenn zwei Prozesse das
> >File überwachen!

Nochmal warum es nicht funktioniert:

- proc A und proc B überwachen.
- proc C schreibt neue mail
- proc A stellt fest, mtime > atime
- proc A liest Änderungen (setzt atime)
- proc B merkt nichts, weil atime schon wieder neuer

A und B sind natürlich wechselbar. Einer merkt es, der andere nicht.

> Dann müssen sie sauber mit utime(3) zurücksetzen. 

(würde race condition erlauben)

> Und ja, mutt macht das schon immer so. 

wahh, tatsächlich, Hammer!

Ich hab jetzt ne Stunde oder so gegoogelt und rumgelesen und ausser
Problemen mit diesem Verhalten nichts gefunden, insbesondere nicht,
warum man auf diese Idee kam.

Wenn ich wissen möchte, ob sich ein File geändert hat, seit ich es
gelesen hab (Zeitpunkt X), prüfe ich doch, ob dessen mtime neuer ist als
Zeitpunkt X?! Wie kommt man darauf, die atime zu verwenden? Was ist,
wenn ein anderer Prozess das File auch liest?

> Es ist es auch der mit Abstand schnellste Weg, es gibt keine
> Alternativen. 

Ich hab sowas schon in etlichen Scripten gemacht. Ich hab mir immer
mtime gespeichert, das file gelesen und dann gewartet, bis mtime >
last_mtime wurde. Was ist daran falsch/schlecht/langsam?

> Die Dateigröße geht nicht, komplett MIME-parsen dauert
> zu lange und müsste blockieren. Für Systeme mit kaputter atime hatte
> mutt früher eine compile-time Option, die mittlerweile runtime ist
> (auf ftp.mutt.org sollte noch irgendwo fixatime.c rumliegen für cron).

ja, hab ich gefunden. Grösse ist meiner Meinung genauso falsch, wenn
eine neue Mail mit 2K reingeht und eine andere mit 2K gelöst wird,
bleibt die Dateigrösse ja konstant.

Ist mutt ein Highlander?!

Haut mich völlig vom Hocker, so einen Korken in mutt zu finden, dachte
immer, mutt `macht alles richtig'. Komisch. 

Weiss jemand, warum man das mit dem atime macht?

> >Natürlich ist es schneller, wenn die Daten so liegen, wie man sie gerade
> >verarbeitet. Daher sollte ein mbox für viele kleine Mails noch schneller
> >sein. Noch schneller sollte eine ramdisk sein.
> 
> Ohne header caching und sonstige "Tricks" ist 1 File pro Mailbox immer 
> schneller als 1 File pro Mail, weil nicht nur seeking fast komplett 
> entfällt, sondern noch mehr overhead wie readdir(), tausende zusätzliche 
> open()/fopen()-Aufrufe, etc. Das kann teilweise erheblich werden. mbox 
> war bei mir schon immer schneller als Maildir ohne Cache.

Nein, eben nicht /immer/. Hat man grosse Dateien, ist mbox langsam, weil
man (ohne index, was ja mbox erstmal nicht hat) ja u.U. Megabytewise
MIME Anhänge parsen müsste, um die nächste Mail zu finden.

Eigentlich ist es ja durchaus elegant, das Filesystem als Index zu
benutzen. Ich meine, dafür ist es ja da! Es gibt Resourcen (u.A.) Namen,
man dann da was lesen/schreiben - genau, was man hier braucht und bei
maildir ja verwendet wird.

> Für Archive ist mbox mglw. eine Wahl. Aber sonst nicht.
> 
> Es geht bei den Locking-Problemen nicht primär um den MUA sondern darum, 
> dass dir irgendjemand in die Mailbox schreiben kann, während du sie 
> ebenfalls schreiben willst. Das kann z.B. auch procmail statt einem 
> anderen MUA sein. 

Na ja, lokal mit flock oder fnctl locking funktioniert ja (jedenfalls
hatte ich früher, als ich sowas benutzt hatte, keine Probleme im Falle
ein procmail und ein PINE oder mutt), oder? So theoretisch jedenfalls.
Nur halt nicht ganz immer...

> Oder: ein Tool könnte für Manipulationen Offsets 
> berechnen, etwas anderes rechnen und dann mit den Offsets schreiben 
> wollen. In der Zwischenzeit könnte sich das File aber so geändert haben, 
> dass die alten Offsets jetzt völlig falsch sind, ergo: Mailbox kaputt.  

Ja, das geht nicht. Man muss exklusiv locken und umkopieren, bei jeder
Änderung. Schreibt man Änderungen nicht sofort, muss man das lock halten
und kein anderer kann schreiben.

In solchen Fällen (mbox als spoolfile) ist das meiner Erfahrung nach
schnell extrem tötlich langsam - aber mailbox sollte doch nicht
kaputtgehen...

> Das ist zwar jetzt arg konstruiert, aber im Prinzip schützt das Locking 
> nicht vor kaputten Foldern; 

ja klar, wer sich nicht an dsa locking hält... Aber wer sich nicht daran
hält, kann die Datei auch einfach löschen, ist's auch kaputt...

> also entweder ein Mailformat ohne Locking (Maildir) oder was anderes,
> wo nur ein sauberer MDA die Zustellung übernimmt (und wo der Storage
> abstrahiert ist, d.h. nur so Funktionen wie Nachricht löschen,
> anhängen, ersetzen, etc. nach außen sichtbar sind, kein Seek, keine
> Offsets).

Letzters kommt IMHO maildir schon recht nahe. Man hat
Nachrichtenobjekte, paar Flags/Zustände, aber viel mehr eigentlich
nicht. Die Operationen erzeugen, löschen etc. sind
Dateisystemoperationen, das Juhunix kümmert sich darum, dass das
funktioniert. Eigentlich ist doch ein Filesystem genau dafür da. Macht
Squid `in diesem Sinne' genauso. Hat irgendwie etwas, finde ich.

> >Warum muss man die Anwendungen anpassen?
> 
> Weil eine nicht-angepasste Anwendung auf Inodes in zufälliger 
> Reihenfolge zugreift und (meinen Tests nach) um Faktor >10 langsamer 
> ist.

Ja, hast Du in einer anderen Mail detailiert erklärt, danke.
Interessante Situation die zu `komischen' Anforderungen führt. Na ja,
anderes Thema.

> [ mbox mit Index ]
> >> Aber das Hauptproblem an dem Ansatz ist: jetzt hast du nicht 1x sondern 
> >> 2x Locking.
> 
> >(Wieso, Du musst doch nur den Index locken?)
> 
> Wenn man die mbox und den Index ändert muss 2x locken.

Warum muss man die mbox+ (ich nenn das mal anders, weil mbox mit Index
ist ja nicht mbox, weil mbox kennt sowas ja nicht) locken? Man kann doch
definieren, dass man die Index immer lockt, das gilt dann immer für mbox
mit. Theoretisch könnte man die mbox lesen wollen ohne index zu lesen,
aber dann muss man laut dieser Konvention halt trozdem den Index locken.
Damit ist mbox+ und Index eine logische Resource.

> >Nur leider funktioniert der Ansatz nicht gut... Zip wird da ja schon als
> >Beispiel genannt. Im Test ein maildir (Mailingliste) mit 689
> >Dateien:
> 
> Dass Kompression pro File u.U. schlechter ist, hatten wir ja schon. 

Ja sorry, mein fetchmail war noch gar nicht durchgelaufen, daher hatte
ich die anderen Mails zu dem Thema noch nicht gesehen, ja blöd...

> Wenn aber für Backups in einem tgz an der falschen Stelle ein bit
> kaputt ist, dann ist der ganze Block hin. Wenn jedes File komprimiert
> wird, ist nur 1 File hinüber (und da evtl. auch nur 1 Block). Hat
> alles Vor- und Nachteile.
> 
> Ich habe den Link nur eingeworfen wegen der Index-Problematik für tar, 
> nicht wegen der Kompression. Ein solches Verfahren mit n Files pro 
> "Container" würde das Problem lösen, weil der Index eingebaut ist. Und 
> man bekäme join/split for free.

tar kann das doch irgendwie, weiss nicht mehr wie, aber man konnte `mt
seek' benutzen um mitten ins Band zu spulen (was ein DAT verdammt
schnell kann, da ist ne Menge Intelligenz dabei, glaube ich), dann
loszulesen und das file zu finden. Ich hatte sowas mal ausprobiert (fand
es aber zu unhandlich, und da meine Datensicherung eh zweistufig über
Festplatte ist, brauchte ich das auch nie. Überhaupt hab ich bloss
gaaaanz selten ein einzelnes File aus'm tar geholt). Das tar war
natürlich nicht komprimiert (und auch die Hardwarekompression vom DAT
hatte ich immer aus). 

Ein Nachteil ist, dass man das index / blocknummern file extra braucht.
Kann man sich hinten aufs Band schreiben oder auf Platte halten (wenn
Platte weg ist, braucht man eh das ganze Band).

> >Der Blog schreibt aber ja auch nur, dass im Falle eines Restores es
> >lange dauert, wenn man nicht weiss, wie die Datei heisst, die man als
> >einzige restoren möchte, was ja auch eher selten ist und anders gelöst
> >werden kann (log file aufheben, -vR verwenden, ...).
> 
> Aber selbst dann muss alles erst entpackt werden, weil ja das tar-File 
> als solches komprimiert wird. 

Na ja, wenn man es nicht komprimiert haben möchte, weil es eine
Bandsicherung ist, komprimiert man es einfach nicht, oder? Das mal
unabhängig von dem Problem.

> Der Container hätte da enorme Vorteile, weil man den Header nicht
> komprimiert. Man kann also ohne Dekompression und mit ein paar Seeks
> von Header zu Header springen und den durchsuchen. Da sollte die
> Datenmenge keinen Einfluss haben; ein tar -ztf je nach Größe dagegen
> dauert u.U. lange und erzeugt Last.

Wie sollte das gehen, wenn Du z.B. ein sparse hast oder ein anderes sehr
gut komprimierbares File? Es darf natürlich nichts "zentrales" geben
(also keinen Index oder so), weil der könnte ja kaputt gehen. Bei tar
geht dann `nur' der schnelle Zugriff nicht mehr, aber man kann den
langsamen benutzen.

Das "von Header zu Header springen" ist auf einem Band tötlich. Es kann
schnell spulen, dabei aber keine Datenlesen (eventuell
Positionsmarikierungen, aber keine Nutzdaten). 

(Natürlich lässt sich ein Fall konstruieren, wo genau das von Header zu
Header springen ideal ist, klar, ich will ja nur sagen, dass es dann
aber auch nur das ist, nämlich ein konstruierter Fall :-))

> Soll heissen: 'tar ... | gzip > foo' ist zwar Unix aber vom Prinzip 
> kaputt. :)

Ich finde es schon richtig, man darf es halt nur nicht blind überall
benutzen! z.B. eben nicht für Datensicherungen auf Bänder oder als
Archiv, wo man einzelne Files rausklauben können möchte.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.