similar to: Message file prefetching to memory

Hi -- I am trying to compile 2.2 (acd76b5272e9) at FreeBSD 9.0: | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I/usr/local/include -std=gnu99 -O2 -Wall -W -Wmissing-prototypes \ -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 \ -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 \ -I/usr/local/include -MT fs-posix.lo -MD -MP -MF

Add wrappers around posix_fadvise and use them in places we were calling posix_fadvise directly before. Also in virt-builder we were doing this (and ignoring the result): posix_fadvise (fd, 0, 0, POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED); However the POSIX_FADV_* flags are _not_ bitmasks! In fact POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED == POSIX_FADV_NOREUSE so we were giving a completely

The biggest problem with getting v1.0 out was getting its index file code stable. v1.1 plans included doing large changes to the index file code, so it's important to get the new code stable as soon as possible. Since I've managed to stay pretty productive for the last few weeks, I've been mostly just coding the index changes. Once I'm sure that the code is again fully working

Hello! I am writing a Linux server, and I want to pre-fetch a number of CIFS files and cache locally. The files are on a CIFS share mounted as read only. I was planning on opening the file, calling posix_fadvise(........,POSIX_FADV_WILLNEED) on the file descriptor, and then closing the file. Will this work? Is there a better way of doing this? Thanks!! Aaron

Bug Report: We had one of our solr server down for a while, then observed a lot of "Warning: fscking index file " actions. Version 2.2.27 with auto fsck. A follow up investigation shows direct one to one relationship between solr error and subsequent fscking. The fscking lasts for quite a long time (for at least an hour) when the mailbox is concurrently accessed. Thank you. Netfront

I don't think anyone uses dbox currently, so the whole format could still be redesigned. So I was thinking about doing two major changes: 1. Rely on index files a lot more. The flags are already stored in index files, so there's no need to waste I/O updating them to dbox files all the time. They could still be updated (if indexes get deleted, the flags aren't all gone), but less

I was thinking about documentation for alternate storage. We have a few mentions at: http://wiki2.dovecot.org/MailboxFormat/dbox http://wiki2.dovecot.org/Tools/Doveadm http://wiki2.dovecot.org/Tools/Doveadm/Altmove But I was thinking it would be helpful if there could be a page about alternate storage. I could write the page, but I currently have so many unknowns that I think it would be

http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc6.tar.gz http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc6.tar.gz.sig I've finally finished all of my email backlog. If you haven't received an answer to some question/bugreport, resend the mail. This is hopefully the last v2.1 RC. If I don't receive any (serious) bug reports about this release in next few days, I'll just change

http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc6.tar.gz http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc6.tar.gz.sig I've finally finished all of my email backlog. If you haven't received an answer to some question/bugreport, resend the mail. This is hopefully the last v2.1 RC. If I don't receive any (serious) bug reports about this release in next few days, I'll just change

http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta9.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta9.tar.gz.sig Some changes since beta8: - This release should work perfectly with NFS attribute cache enabled. - Fixes to handling what should be written to cache file and when - Some index handling optimizations - IMAP LIST: dbox and cydir can now return children state Beta9 will

Hi, Here is the problem that occured: #sudo doveadm -D altmove -u vv at vito.pp.ua all works properly and moves all storage to alt dir. However, to move it back to default storage I add '-r' by manual: #sudo doveadm -D altmove -u vv at vito.pp.ua -r all That seems behave like the original command ignoring '-r'. my dovecot conf: # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf

The way we used posix_fadvise was wrong, and yet right! Rich.

Hi, I'm using Dovecot 2.2.33.2 on a RHEL 7, new installation. My log is full of : Error: INDEX_FOLDER/dovecot.index.pvt reset, view is now inconsistent or Error: INDEX_FOLDER/dovecot.index.pvt view is inconsistent when shared folder is never touched and empty. UserA share XXXXX folder with UserB, if XXXXX folder is new (never touched) and empty every time UserB looks in that folder, an

v2.1's imap/pop3 processes are linked with OpenSSL by default, because of imapc/pop3c storages. I wonder if you notice any actual (system-global) memory usage reduction when compiling without those and you have thousands of imap processes? ./configure --with-storages=mdbox sdbox maildir mbox cydir I guess I could try it myself also but maybe someone else wanting to reduce memory usage is

Writing "file-like" plugins is hard because you have to implement your own .zero, .trim, .extents, etc, and that is very complicated. However implementations of these functions already exist in the file plugin. By factoring out the file plugin into a separate "fileops" mini-library we can reuse these implementations in other plugins. This refactoring commit creates a new

http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz.sig mbox users really should upgrade, because by sending a message with a huge header you could basically cause a DoS (this problem exists only with v1.2.x, not with v1.0 or v1.1). - mbox: Message header reading was unnecessarily slow. Fetching a huge header could have resulted in

http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz.sig mbox users really should upgrade, because by sending a message with a huge header you could basically cause a DoS (this problem exists only with v1.2.x, not with v1.0 or v1.1). - mbox: Message header reading was unnecessarily slow. Fetching a huge header could have resulted in

Hi, Here is the problem that occured: #sudo doveadm -D altmove -u vv at vito.pp.ua all works properly and moves all storage to alt dir. However, to move it back to default storage I add '-r' by manual: #sudo doveadm -D altmove -u vv at vito.pp.ua -r all That seems behave like the original command ignoring '-r'. my dovecot conf: # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf

Hi! After searching for hours now, I give up and have to ask here. I try to use the expire plugin but it always tries to expire my mails instead of the mails of the user. I read about the "Mail location setting problem (v1.1-v1.2) and configured a "mail" extra field in the userdb, but that doesn't have the effect I want. I have not idea, what I could try out more, so I ask

Mainly intended for future support of key-value (etc.) databases, but this is probably useful even for regular disk I/O. By using async I/O for disk access, the OS could more intelligently do seeks on disk to read the wanted data with less latency. Problem #1: Accessing message body while searching (e.g. SEARCH BODY). The idea is that searching wouldn't block. Caller would typically use