Názory k článku
Thunderbird bude poštu ukládat ve formátu Maildir
-
pecko (neregistrovaný)
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... -
Dramon (neregistrovaný)
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 :) -
jardik (neregistrovaný)
pozri si aky format ma mbox... http://tools.ietf.org/html/rfc4155
-
firzen (neregistrovaný)
Každopádně je to krok, který odsune odpovědnost za rychlost práce s databází na souborový systém. A to je určitě dobře, protože je lepší zapracovat na souborovém systému, který pak bude lepší na všechno, než aby každý program na vlastní pěst obsahoval svoje vlastní pseudo-dokonalé řešení. Nebo se snad pletu? :-)
-
BobTheBuilder (neregistrovaný)
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$...
-
lol (neregistrovaný)
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.
-
??? (neregistrovaný)
Vo vsetkych testoch a benchmarkoch ktore sa kedy robili bol MBox vzdy rychlejsi ako Maildir.
.................................................................
Mna vobec zaraza, ze sa nieco take riesi. Pretoze podla mna, imap klient(akym thunderbird je) si ma ukladat iba hlavicky mailu a nic ine nestahovat. Toto je presne aj problem outlooku, kde to co vidi outlook je vzdy odlisne od toho, co je fyzicky na servry.
.................................................................
Drviva vacsina ludi aj tak vyhladava postu podla toho, co je v hlavicke a malokedy chce vyhladat nieco co je v tele mailu. Naviac, thunderbird sa zvacsa pouziva na windows strojoch, ktore nemaju velmi dobry memory managment. Ak ma klient v adresary cca 50000 mailov, tak prehladanie povedzme 500MB MBoxu na dotaz od koho to prislo je omnoho rychlejsie ako prehladanie 50000 suborov. Samozrejme za predpokladu, ze thunderbird(imap klient) si stahuje naozaj iba hlavicky mailov a tak je MBox relativne maly-co je ale bohuzial v default stave vypnute. -
Sten (neregistrovaný)
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
-
??? (neregistrovaný)
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) -
Fantozzi (neregistrovaný)
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 -
Nox (neregistrovaný)
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.
-
idaho (neregistrovaný)
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? -
Hugo (neregistrovaný)
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.
-
Sten (neregistrovaný)
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á
-
FAWN (neregistrovaný)
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.
-
Nox (neregistrovaný)
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. -
Petr (neregistrovaný)
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.
-
SSD (neregistrovaný)
Daj si hladat s podmienkov ak predmet neobsahuje fasdkljfahjkhfjkafkla 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.
-
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
-
SSD (neregistrovaný)
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..
-
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).
-
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).
-
No nevim, nevim....
rsync pro windows sice je a sam jej intenzivne pouzivam, ale synchronizace adresarove struktury s desitkami az stovkami tisic souboru trva siiiiiiiiiiiiilene dlouho.
Delam tak zalohy namerenych dat, takze i kdyz vetsina souboru zustava stejna a nove adresare maji prumerne 100 - 3000 souboru, zabira synchronizace kolem pul hodiny.
Pod linuxem je to naopak otazka okamziku - coz je velmi zajimave.
Rychlejsi je spustit Totalcommander a synchronizovat to pres nej.Aby to netrvalo vecnost, zipuji adresare ktere se pravdepodobne nebudou delsi dobu pouzivat, ale prace s daty je pak docela opruz :-(
Synchronizace je pres USB externi disk:
data->USB zaloha
USB zaloha -> pocitace s win nebo lin
Souborovy system je samozrejme FAT kvuli nezavislosti na OS.
Verze rsync pro windows je "standardni model", myslim z cygwin nebo unixutils.
ČLÁNKY DO MAILU