similar to: Corrupted index cache file dovecot.index.cache: invalid record size

We are seeing some poor performance recently that is focused around users with large mailboxes (100,000 message /INBOX, 80,000 message subfolders, etc). The performance problem manifests as very high system% utilization - basically iowait for NFS. There are two imap servers with plenty of horsepower/memory/etc. They are connected to a 3050c cluster via gig-e. Here are the mount options:

Hello - I know I am not the only one that will be trying, or has tried this before. Here are my questions! NFS Clients, multiple servers running dovecot - linux with 2.6 kernel with relevant patches (utime, etc) Backend - netapp filer End users - various clients all running IMAP It looks like 1.0.beta8 is definately the way to go. I have a few questions with regards to setup. Is it now

Greetings - I'm now in the last couple of weeks before going live with Dovecot (v1.0.3) on our revamped IMAP service. I'd like to double-check about the best mount options to use; could someone advise, please? I have three separate directory trees for the message store, the control files and the index files. These are arranged as follows: Message Store Mounted over NFS from

Picture: A set of very similar UN*X IMAP servers all NFS-mounting their INBOX area (traditional Unix format) from a common "/var/spool/mail" area; activity for any given user ought to be within one box although this cannot be 100% guaranteed. There is the risk of multiple simultaneous access (e.g. simultaneous LDA/delivers; simultaneous LDA/deliver and user-driven IMAP update; etc.).

I'm running beta7 on two machines, with maildir on NFS. I have lockd running on all machines. I've found that Dovecot is highly unstable with NFS when accessing a mailbox on more than one machine at the same time. Both dovecot machines have: mmap_disable = yes lock_method = fcntl NFS is version 3, exported from a third linux machine. All machines are running 2.6.9 kernel. Any ideas

Hi, I experimented with Dovecot a while back and our site is now taking the plunge to switch to it from the UW IMAP server when we rejig the topology of our mail store and IMAP servers. Currently we have a farm of 5 IMAP servers running the UW server. Each has locally attached disk used to store people's mailboxes. Each user is allocated to one of these five servers and can only

Hi, Are there any big Dovecot sites (say 50,000-100,000) users on this list? What sort of hardware do you use. What sort of problems do you see? Many thanks, Jonathan.

Background: I'm new to dovecot (although with many years Washington IMAP behind me). We're considering migrating from Washington IMAP to dovecot on the main service here, and have just started trying dovecot, using RC7. Washington, IMAP has the usual(-ish) "/var/spool/mail" shared area for the INBOX (trad. UNIX "From " format); a user's folders default to being

dovecot: Nov 08 04:04:23 Error: IMAP(user): open() failed with file mailstore/user/Maildir/.Alerts/dovecot.index.log.2: Too many open files dovecot: Nov 08 04:04:23 Error: IMAP(user): open(mailstore/user/Maildir/.Alerts/tmp/1162976663.P4853Q1817.server) failed: Too many open files dovecot: Nov 08 04:04:23 Error: IMAP(user): open() failed with file mailstore/user/Maildir/dovecot.index.tmp: Too many

(Using dovecot 1.0 RC7 on Fedora Core 5) <scene set> Hitherto we have used UW-IMAP on a "farm" of Linux machines mounting NFS from a NetApp. (The UW-IMAP author doesn't like use of NFS, but with careful use of NFS mount arguments ('noac,actimeo=0' etc.) and trying to ensure that all activity for a given user takes place within one machine in the farm, we seem to

We have and nfs mount from a windows pc nfs server. A file is created on the server, but can take as long as 50 seconds to become available on the client. We are running Centos 5.2 (final), using NFS version 3. Is there anything we can do from the client side to see the file more quickly. The files are very small, usually about 1k _____________________________________ "He's no

Hi guys I'm about to embark on a project replacing a legacy single mail server running proprietary software with a cluster of Dovecot servers. We clearly need a shared mail store for these servers, but we are not happy with simply using a server running NFS as this becomes a single point of failure. What have other people used? AFAICT our options are: * A shared block device (Fibre

On Nov 8, 2014, at 1:52 PM, Steve Read <sd_read at hotmail.com> wrote: > I have made changes but it is still the same. That is when the server gets the lowbat/noAC signal it does shut down as expected but the slave does not. > > Perhaps it makes sense for me to list the present settings: > > On the Master: > > nut.conf > MODE=netserver > >

We have a 2-node Oracle RAC that keeps getting the following error: kernel: nfs: RPC call returned error 88 The storage being mounted is netapp. We don't see any errors/issues on the storage itself or the switches this client is connecting thru. The NFS network is a 2-interface ( 2 x 1Gb UTP) bond which shows no errors of any kind. We are mounting with the following mount options:

Hi Timo, We've been running Dovecot with Maildir on NFS for quite a while - since back in the 1.0 days I believe. I'm somewhat new here. Anyway... The Wiki article on NFS states that 1.1 and newer will flush attribute caches if necessary with mail_nfs_storage=yes. We're running 1.2.8 with that set, as well as mail_nfs_index=yes, mmap_disable=yes and fsync_disable=no. We have a pool

I would like to verify my understanding keeping in mind I have a one master and one slave computer. When the master gets the low batt/noAC signal it initiates a broadcast packet(s) on port 3493. 1) Is this correct? Then the slave computer must have this port open and it listens on this port for the shut-down command. 2) Is this correct? On the slave if I run the following: steve at MyDesktop:~$

Greetings - Now that users are beginning to pile up more on our new Dovecot-based IMAP service I'm seeing a small number of entries like this in the logfiles: Corrupted index cache file /mailstore/index/o/ozw100/.INBOX/ dovecot.index.cache : invalid record size We are using Dovecot 1.0.3 with Maildir folders served over NFS from NetApp filers, but the index files are stored on local

Hi All, I am looking for advice on how to cure a constantly-crashing NFS server which crashes every few hours, or at least, every few days. The kernel log file (below) points toward NFS as a likely cause. The system disk is a 3ware 8000 series RAID1 mirror. The data disk is using a 3Ware 9000 controller to produce two RAID1 devices; these are then striped (RAID0) in software to form a RAID 10

Hi all, I'm using Debian (testing) for my office mail. I'm using sendmail and Dovecot to deliver email to clients over IMAP using mbox format. I want to move over and start using Maildir. I know that I can use different MTA's to do the job, but I really like sendmail, and I run additional sendmail servers across the my internal and external networks. I'm probably

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