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?
- 336 megtekintés
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).
- A hozzászóláshoz be kell jelentkezni
Egy meglévő rendszerben szeretném bekapcsolni ezt a funkciót, ha megbízható. Az FS ext4.
Az imap_zlib-et köszi.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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...
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> É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
- A hozzászóláshoz be kell jelentkezni
Én meg erre nem is gondoltam ... de igazad lehet. :)
- A hozzászóláshoz be kell jelentkezni
"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."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Ezt nem használom, de elvileg van ilyen.
##
## Mail attachments
##
# sdbox and mdbox support saving mail attachments to external files, which
# also allows single instance storage for them. Other backends don't support
# this for now.
# Directory root where to store mail attachments. Disabled, if empty.
mail_attachment_dir =
# Attachments smaller than this aren't saved externally. It's also possible to
# write a plugin to disable saving specific attachments externally.
mail_attachment_min_size = 128k
# Filesystem backend to use for saving attachments:
# posix : No SiS done by Dovecot (but this might help FS's own deduplication)
# sis posix : SiS with immediate byte-by-byte comparison during saving
# sis-queue posix : SiS with delayed comparison and deduplication
mail_attachment_fs = sis posix
# Hash format to use in attachment filenames. You can add any text and
# variables: %{md4}, %{md5}, %{sha1}, %{sha256}, %{sha512}, %{size}.
# Variables can be truncated, e.g. %{sha256:80} returns only first 80 bits
mail_attachment_hash = %{sha1}external storage for mail attachments
Ez is érdekes lehet:
- A hozzászóláshoz be kell jelentkezni