Próbálom tesztelni a Dovecot működését zlib használatával.
Elvileg tudja azt, hogy a már letárolt levelek egyszerűen gzip-pel tömöríthetőek, és ez nem zavarja a működését.
A gyakorlatban bekapcsolva a zlib plugin-t, valóban továbbra is működőnek tűnik. De ha kitömörítem a leveleket, módosítok a tartalmukon - úgy, hogy a méretük ne változzon -, majd újra betömörítem, a kliensben továbbra is az eredeti tartalmat látom.
A kliens oldalon már kikpacsoltam a cache funkciót és töröltem a cache-t (egy webmail), a szerver oldalon pedig a user Maildir mappájából töröltem a dovecot fájlokat, amiben azt hittem, a cache is van. De továbbra is ez eredeti tartalmat látom, nem a módosítottat.
1 - Tudja valaki, hogy a Dovecot hol tárol még cache-t, vagy hogy lehet megkérni rá, hogy ne keseljen?
2 - Használja valaki éles üzemben a Dovecot zlib modulját? Ha igen, érdekelnének a tapasztalatok, mennyire megbízható? És csak a zlib modult használja-e, vagy az imap_zlib-et is?
Hozzászólások
Nekem nincs vele tapasztalatom, még sohasem jutott FS szint helyett ezen a szinten tömöríteni.
De Te miért épp a Dovecot szintjén tömörítesz? Nem lenne kényelmesebb az FS szintjén? Pl. btrfs vagy zfs alapon. Teljesítmény nagyjából ugyan annyi, tömörítési hatásfok kb. ugyan annyi, csak a felhasználói szoftver szintjén minden ugyan úgy marad, nincs járatlan út.
Az imap_zlib egyébként nem a tárolás során érdekes, hanem a klienssel folytatott kommunikáció során lehet tömörített az adatátvitel (ha a kliens is támogatja és kéri).
Egy meglévő rendszerben szeretném bekapcsolni ezt a funkciót, ha megbízható. Az FS ext4.
Az imap_zlib-et köszi.
Csak egy közbevető kérdés: mi köze a dovecotnak ahhoz, hogy a kliens mit/hol/hogy tárol?
Az, hogy a dovecot tömörítve tárolja a leveleket a szerveren, az egy jó dolog - de ettől még a kliens tömörítetlenül fogja megkapni POP3(S)/IMAP(S) protokolon a levelet, amit a kliens tárol ahogy tárol és slussz.
> módosítok a tartalmukon - úgy, hogy a méretük ne változzon -, majd újra betömörítem
mit modositasz pontosan? a headert? a body reszet?
a pop3/imap kliensek cska a level uuid-jet szoktak lekerni, es ha nala az megvan mar letoltve akkor nem szedi le ujra.
az uuid-et pedig beerekzeskor (lda) szokta szamolni (pl. checksum, vagy csak egy sorszam) es beleirja a letarolt mail headerjebe...
Ha jól értettem, akkor a kliens cache is takarításra került, tehát nem lesz meg nála a body.
Viszont a dovecot csak tárolja tömörítve a leveleket, amikor elkérik tőle, akkor kitömörítve adja a kliensnek, ami azt ebben a formában, azaz tömörítetlenül fogja tárolni.
Én még mindig ott vagyok elakadva, hogy attól, hogy a szerver oldal tömörítve tárolja az adatot, miért kéne a kliensnek is tömörítenie? Ha tud is ilyet a kliens, azt akkor is a kliens oldalon kell bekapcsolni - nem?
Lehet hogy feluletesen olvastam, de nem lattam, hogy a kliensoldalon is kene lennie tomoritesnek.
Viszont akkor mar... en egybol valami cli toolal (fethcmail pl.) esnek neki letoltogetni a leveleket, hogy latszodjon, hogy pontosan mi tortenik, illetve altalban egyszerubb (meg scriptelhetobb) a tiszta kornyezetbol inditas.
Szoval en arra gyanakszom, hogy megis van/marad valami kliensoldali cache. De... ez csak tipp.
1 - Igen, a kliensnek nem kell tömöríteni.
2 - Valóban úgy tűnik, hogy a kliens oldalon volt a rejtett kes. Teljes kliens újraindításnál nem jelentkezik az anomália.
5 év courier és 15 év dovecot alatt én nem találkoztam ilyen megoldással, pedig elég sokat csavartam a dovecot-ot. Sok leírást, fórumot olvastam dovecot témában. Most rákeresve valóban tudja, de szerintem nem nagyon van kitaposva ez az út így nem mernék rá alapozni. Inkább a többek által is említett zfs vagy btrfs vonalon próbálkoznék, ha szükségem lenne rá. Már csak a hordozhatóság miatt is, ami a jövőben biztosítja nekem és a megbízóim számára az üzletmenet folytonosságot.
Én a zlib mellett még crypt-et is használok.
dovecot.conf: zlib_save = lz4
mail_plugins: quota acl zlib mail_crypt mail_crypt_acl mail_log notify fts fts_solr listescape replication
mail_plugins_imap: quota imap_quota imap_acl acl zlib imap_zlib imap_sieve mail_crypt mail_crypt_acl notify mail_log fts fts_solr listescape replication
mail_plugins_lmtp: quota sieve acl zlib mail_crypt mail_crypt_acl fts fts_solr notify listescape replication
Köszönöm. Az eddigi tesztjeim alapján is megbízhatóan megy a zlib plugin. Csak tárolásnál tömörít, minden más esetben az eredeti tömörítetlen formában mennek a levelek. Olyannyira, hogy még az antispam plugin spool2dir backendjének mappájába is tömörítés nélküli formában kerülnek a levelek.
Azt azért hadd kérdezzem meg, hogy a crypt mellett is tud érdemben tömöríteni a zlib? Én azt várnám, hogy a titkosított tartalmat már nem tudja jól tömöríteni.
> Én azt várnám, hogy a titkosított tartalmat már nem tudja jól tömöríteni.
en meg azt varnam, hogy elobb tomorit es utana titkosit
Én meg erre nem is gondoltam ... de igazad lehet. :)
"De ha kitömörítem a leveleket, módosítok a tartalmukon"
Nekem csak annyi a kérdésem, hogy de miéééért? :)
Mi ennek a gyakorlati haszna? Vagy mi történik a levéllel?
"Sose a gép a hülye."
Egyszerűen csak tesztelésből, hogy lássam, hogy valóban a tömörített tartalmat kapja meg a kliens, és nem valami kesből mutatja azt.
Lazán kapcsolódik, a múltkor ezt gondoltam ki, hogy tök jó lenne, ha a mailből a csatolmányokat ki tudná szedni, valahogy külön tárolni és valami hash-el azonosítani. Van erre bármi megoldás?
"Sose a gép a hülye."
Ezt nem használom, de elvileg van ilyen.
external storage for mail attachments
Ez is érdekes lehet:
Problems with compressed mail_attachment_dir