Thunderbird bude poštu ukládat ve formátu Maildir

ze to v prvom rade pomoze pri tych zahadnych stratach mailov a roznych disfunkciach a pod:) cokolvek, co zrychli a stabilizuje cinnsot tohto klienta je vitane:)

1 subor = 1 mail mne osobne neznie velmi rychlo.

hm, nie som nejaky specialista na databazy, ale neni horsie, ked obsah mailu musis vyhladat v nejakom subore v jeho casti, ako ked vo filesysteme ukazes na subor? aj vyhladavanie mailov moze byt takto podla mna rychlejsie. a navyse to podivne kompaktovanie foldrov... v maildir zmazes mail, zmazes subor a nic sa nedej. v mbox ak zmazes mail a nekompaktujes folder, po case mas obrovsky adresar, ktory je ale prazdny:) maildir tomu podla mna trosku pomoze. aj komaptibilita bude lepsia:)

Neni to rychlejsi. Naopak je nepatrne rychlejsi vyhledavani v jednom souboru, protoze se samozrejme neprocita celej soubor, ale pouze se precte index a pak presune pointer primo na adresu mailu. Pokud je kazdej meil v jednom souboru, dela se to samy plus se musi otevrit jeste ten soubor s mailem.
Ta druha cast je samozrejme pravda...

Oni tam určitě použijí nějaký urychlovací element, například SQLite databázi. Potom se bude rychle načítat obsah složky a tělo mailu to najde dle názvu souboru. Pokud se databáze rozbije, nebo bude inkonzistentní, na pozadí se to samo opraví.
Tedy doufám, že to udělají nějak takto :)

pozri si aky format ma mbox... http://tools.ietf.org/html/rfc4155

porad lepsi nez 1 fragmentovany soubor s 10000 pochybne zaindexovanejma mailama.

Mám jisté zkušenosti s roaming (cestovními) profily. Toto je VELMI špatné řešení, protože zkopírovat po síti soubor cca 1GB není zase takový problém, jako zkopírovat objem 1GB ve 2000 samostatných souborech - režie otevření/vytvoření a uzavření souboru krát 2000 je mnohem vyšší, než samotné kopírování.
Tohle by mělo smysl v samostatné instalaci u účtů, které se stahují přes POP3. U indexů účtů IMAP to povede jen k degradaci.

Základní problém je spíš v tom, že samotné cestovní profily jsou VELMI špatné řešení. Pokud vím, tak tohle se jednoduše nepoužívá. Pro uživatele se vytvoří normální adresář na sdíleném svazku (ve správci uživatelů jde tuším uživateli přidělit samostatný HOME adresář) a složky z profilu se přesměrují tam.

Opravdu nevím, kterého chytráka napadlo kopírovat celý uživatelům home při přihlášení ze serveru na stanici a při odhlášení zase zpět. Holt M$...

to co tebe pride ako nedobre je uplne irelevantne. Maildir ma plno vyhod - za zmienku staci spomenut ze v nazve subory je obsiahnuty stav mailu (replied, forwarded, unread, read), jeho velkost a utime. Takze uz len z jedineho readdir() je mozne vyfiltrovat / zoradit maily. Priklad: 1182972806.13892­.xyz,S=3350:2,RS

Rovnako nacitanie hlaviciek je efektivnejsie - nacita sa header a pri prvom \n\n sa skace na dalsi subor. Namiesto seekovania v jednom subore. Odhliadnuc od toho ze operacny system tieto operacie dokaze cachovat a kedze v mailoch sa fyzicky nic nemeni, su tieto operacie extremne rychle. Naopak neustale editovany subor (v stojim prikladom 50 000 mailami a dajme tomu velmi poddimenzovany odhad 5GB) cachovat nejde.

Maildir pouzivaju IMAP servery na ukladanie mailov a nemaju s tym ziadne problemy. Nevidim dovod preco by s tym mal mat problem nejaky mailovy klient pracujuci s radovo zlomkom mailov a teda suborov.

Spoustu lidí používá v TB offline kopie a ty se musí někam ukládat.

OK, tento argument beriem...

Vo vsetkych testoch a benchmarkoch ktore sa kedy robili bol MBox vzdy rychlejsi ako Maildir.

A byl alespoň jeden z těch testů vícevláknový? Při použití více vláken MBox velmi rychle pohoří, protože umožňuje přístup jen jednoho vlákna.

Mimochodem můžete alespoň na jeden z těch testů odkázat? Já našel tenhle test (s jedním vláknem) a tam MBox velmi výrazně pohořel, u hodně pomalého stroje se ještě docela drží (přečtení všech mailů najednou je v sool state opravdu rychlejší, vše ostatní je stejné nebo pomalejší), na rychlém stroji (ve skutečnosti o dost pomalejším než dnešní) a s rostoucím počtem e-mailů nemá MBox šanci

Opera takto ukládá své emaily již odjakživa. Mám takto zaplněno víc jak tisícovku emailů a na rychlosti to není nijak znát. Emaily zobrazí hned a vyhledávání je také rychlé.

Az tam budes mat cca 120 000 mailov ako niektory nasi naruseny jedinci v nasej firme, ktory naviac nie su schopny si potriedit postu aspon podla roku v ktorej to dostali, tak sa ozvi :-) Rad podebatujem na temu rychlost mailovych klientov a podobne.
.............­.............­.............­.............­......
Tym samozrejme nechcem povedat,ze Opera je zla. Bohuzial, v nasej firme sa zubami nechtami drzi ten prasivy outlook, aj ked sa snazime prejst prave na thunderbird(dovod je samozrejme cena a u nas na IT taktiez spolahlivost a ine veci)

Mám v KMailu (Cached IMAP, používá maildir) něco přes milion e-mailů (několik složek má kolem těch sto tisíc; to víte, webové konference) a nemá s tím problém. Nemáte tam spíš problém se souborovým systémem FAT?

120000 mailov netriedenych a Outlook mi akosi nejde dokopy. Cca pred 3 mesiacmi som preklapal na ziadost klienta maily z GroupWise do Outlooku. V inboxe GroupWise ich bolo okolo 25000. A neratam zvysok v Cabinete (dalsie zalozky). Lenze Outlook ich dokazal do inboxu dostat nieco okolo 4600. Takze sa to muselo delit do zloziek po 4000.

GroupWise 6.5
Outlook z MSO2007

je to rychle, ma to totiz index ... tedy seznam vidis hned a az kliknes na urcity email, tak se ti teprve zobrazi ... je to velmi rychle a mene to zatezuje ... odzkouseno na serverech ;-))
prechod mailfile/mbox->mail dir ;-))

Takze kdyz mam v Thunderbirdu 1000 mailu, budu mit na disku 1000 souboru? To bude pekne pomale a fragmentujici.

a co teprve ti co maji SSD disky

SSD disky dodnes nejsou tak rozsirene jako klasicka HDD a i ony maji sve limity v poctu operaci za sekundu. Pri praci pouze s maile to nebude poznat, ale pokud si budu chtit zazalohovat maily, tak budu ty stovky malych souboru kopirovat a urcite nebude rychlejsi nez 1 velky soubor.

Nevidim duvod k takovym obavam z fragmentace. Jak velky mate prumerny email? Jak velkou mate alokacni jednotku (cluster) na disku? I kdyby jeden soubor byl rozdelen na tri kusy ruzne po disku, je to porad lepsi nez kdyz je jeden megasoubor rozdelen na 30 tisic kousku vsude po disku.
Zpusob "email = jeden soubor" jiz davno uspesne funguje u emailovych serveru na linuxu, jsem windowsar, takze ted abych nekecal... postfix?

Myslim, ze o Maildir format sa kedysi pricinili svojim "vynalezom" qmail(inak hnus, R.I.P.) a o rozsirenie nasledne courier server.
Nakoniec - potvrdzuju to aj wiki stranky http://en.wikipedia.org/wiki/Maildir .

Kazdy jeden vacsi system pracuje s Maildir formatom, mbox je uz davno neudrzatelny format. A maildir najma riesi problem konkurencneho zamykania mailboxu.

Ako je to s win FS presne netusim, ale tam vidim vacsi problem ako pri *nix FS, ktore su na toto stavane a maju masivne cachovanie. Kazdopadne, pomoze to aj tam.

Pro NTFS by to měla být také hračka, navíc většinu souborů (protože jsou velmi malé) nacpe do MFT (obdoba linuxové inode table), takže to dokonce nebude ani seekovat tolik jako třeba ext3 (myslím, že Reiser4 má podobnou vlastnost). U FATky je to ale hrůza, ale dobře každému, kdo ji pořád používá

No, samozrejme je to vareni z vody, protoze nezname podrobnosti, ale prave NTFS ma problem s velkym mnozstvim souboru v jednom dir. Proto take MS preferuje velke soubory / databaze jak pro Outlook, tak pro Exchange. Kdyz mate v jednom adresari hodne pres 10 tis, souboru OS ma jiz problem jiz zobrazit obsah slozky nebo tam vytvaret nove soubory. Procesy pak vyhazuji timeouty a tak.

Prace s mnoha sty soubory bude porad pomalejsi nez s 1 velkym, treba kdyz si budu chtit maily nekam zkopirovat na zalohu, nebude to zrovna vyhodne.
E-mailove servery na linuxu to mozna pouzivaji, ale pro bezneho uzivatele ve Windows s NTFS to bude jen zpomaleni.
Osobne v tom vidim spoustu nevyhod. Bohuzel dnesni trend i u programu je spise tisice malych souboru nez par velkych.

Fragmentující jen u horších souborových systémů ... u těch lepších fragmentace, díky pár statisícům mikrosouborů, myslím nehrozí.

Nikoli nezbytně. Na všech počítačích si poštu lokálně ukládám do maildiru (lezu do ní seamonkey -> courier imap) a i při desítkách tisíc mailů to je celkem svižné...

1000 souborů nic není. IMAP servery používající maildir mívají desítky tisíc mailů ve stovkách složek a úplně v pohodě.

Konecne, len dufam ze no nepotrva 5 rokov..

Teraz synchronizujem emaile tak ze medzi notasom a desktopom kopirujem zmenene mboxi co je niekedy an par GB a aj na GB Lanke cakam cez 2 minuty...

Takto by sa preniesli len nove za par stotin..

Na synchronisaci malých změn ve velkých souborech je např. rsync.

Rozhodnutí je to dobré, ale já budu mít asi problém: mám na datovém disku samé větší soubory a i to co tvořím jsou větší soubory (fotky, grafika), takže alokační jednotku mám 32kB - což na kilové maily kterých mám desetitisíce bude celkem maso. Na "filmovém" disku mám dokonce 64kB. I kdybych dal 8kB, pořád to bude slušně nehospodárné. Jak zjistit teď počet mailů v TB? Celkem ta složka má po komprimaci 9,5GB, ale počet mailů nějak nevím jak zjistit.

Daj si hladat s podmienkov ak predmet neobsahuje fasdkljfahjkhfjkaf­kla vo vsetkych priecinkoch a ukaze ti kolko mas vsetych emailov. dokonca si ich tam mozes triedit podla velkosti..

Tu alokaciu mozes oblafnut tak ze si vytvoris sifrovany subor napr. v truecrypte pridelis najmensiu jednotu nasmerujes nan emaile ktore zaroven mas aj sifrovane, ak nemas nejaku staru sumku tak rozdiel vykonu ani nepocitis ba naopak moze to ist aj rychlejsie.

Jaký souborový systém? Novější systémy umí tail packing (ext4, btrfs, ReiserFS, ZFS, JFS), případně ukládat malé soubory přímo do inodů (Reiser4, btrfs, NTFS), takže tomu nevadí, že je alokační jednotka moc velká

No, jestli se opravdu bude ukládat každý e-mail jako samostatný soubor (a nebude to zabaleno např. do nějakého archivu), tak si budu muset najít jiného e-mailového klienta, protože synchronizovat přes Sambu svých asi 8000+ e-mailů v samostatných malých souborech mezi počítači nepůjde… To mám teda radost…

Vždyť i Firefox 4 má v profilu ukládat rozšíření zabalená v XPI (tak jak jsou stažena z internetu) místo jejich rozbalování, aby se ušetřili diskové operace. Moc doufám, že něco podobného udělají i pro poštu, jinak jsem v háji. :-C

O co ti ide, dostanes 30 novych emailov tak sa ti prekopiruje 30 suborov a nie jeden 500MB file. Ja som synchronizoval sambu s rsync a porovnanie 90 000 tisic suborov trvalo cez 1Gbit siet par sekund. Akurad ked isiel kopirovat 2GB inbox a outbox tak to trvalo niekolko minut na linuxe nakolko samba nedala viac ako max 17MB/s. Medzi Win a Win tlaci cez sietovku 60-70MB/s..

Přesně tak. 8000 souborů je pro rsync i po síti trivka.

Jo, z rsyncu mezi unixovými stroji strach nemám, ale co pod Windows přes Unison a Sambu (Windows sdílení)? Tam to bude fest pomalé a já tohle také používám.

tech x tisíc to bude synchronizovat jen jednou. pak uz jen nove dosle emaily, tech budou desitky denne? to uz je jak malina

Jo, jenže Unison stejně musí celý ten adresář vylistovat a o všech souborech zjistit velikost a čas modifikace, aby zjistil, které jsou změněné. To ale přes Sambu docela trvá. Nepsal bych to, když bych neměl podobnou zkušenost s adresáři s fotkami – opravdu to na Windows s Unisonem trvá dlouho.

Asi se budu muset podívat, jestli by pod Windows nějak nešel rozchodit SSH server se spolehlivým zapisováním a čtením souborů se správnými přístupovými právy / časy modifikace. Pokud si Unison spustí přes SSH na druhém stroji lokální Unison (obdobně, jako to dělá rsync), který tam soubory projde lokálně (a přes síť si pošlou jen změny skoro stejným způsobem jako to dělá právě rsync), tak je to samozřejmě o něčem jiném. Z tohoto důvodu to není problém pod Linuxem (ať už s Unison nebo rsync).

Skoušel jsi ssh server z cygwinu? Docela se s tím dá pracovat.

Rsync je i pod Windows, když na to přijde..

rsync je o zrcadlení z bodu A do bodu B. Unison je spíše o sloučení změn v bodech A a B tak, aby v A i B bylo vše. Tzn. Unison toho umí trošku víc než rsync.

Mimochodem, nějaké konkrétní doporučení implementace rsyncu pod Windows? cwrsync mne až tak moc nenadchl. Teď si nejsem úplně jistý, ale byly tuším problémy s českými znaky v názvech souborů (nebo tak něco).

Ja mam ulozene newsgrupy 6 rokov dozadu, nechcem vidiet ako sa trapi disk pri indexacii 50000 suborov

Napr. KMail dlouha leta podporuje zaroven mbox i maildir (osobne pouzivam maildir snad odjakziva a nedam na nej dopustit), pro kazdou slozku to klidne muze byt zvlast. Nevidim jediny duvod, proc by to nemelo jit i u Thunderbirdu.