[Dovecot] Re: extremely slow delete/move operations?

[Gregory K. Ruiz-Ade]

First, I regret saying anything about NFS being involved, since it seems to 
have clouded the issue.  None of the current users on the system are mounted 
with NFS home directories, so, the performance issues seem to be wholly 
contained in the local system.  That said, the local filesystems are 
exported by NFS for other systems (clients NOT running dovecot) to mount.

Dovecot is running on the server where the disks and filesystems are.

To remove a number of variables, I copied my own mail files to my personal 
workstation (no NFS, only one user, dovecot 0.99.11) and had the exact same 
performance for moving messages from one mailbox to another as I did on the 
server.  I have not yet had a chance to test 1.0 beta2.

Roger Weeks wrote:
> I don't understand this at all.  Mounting anything via NFS should  only 
> be done from a remote server, where when you type "mount" at a  
> commandline you see something like:

The following is what I've seen from my own experiences as a Unix admin, 
both in Solaris and Linux environments where a large number of systems need 
to have similar or identical environments.  My first experiences with this 
setup were with Solaris environments; in fact, the default Solaris install 
puts homes in /export/home and automounts them into /home, even if you don't 
turn on NFS services.

This is a rather long-winded response, and isn't strictly related to 
dovecot, but I'm attempting to explain my rationale for excluding NFS from 
the equation in these dovecot performance issues I'm having.

Forgive me if I'm explaining things people here already know. :)

---------------

In large NFS environments, where people can either log on to the server or 
any number of workstations, common things like home directories are mounted, 
on the server, under /export:

-----
/dev/mapper/vg00-homes1 on /export/homes1 type ext3 (rw,nosuid,nodev,usrquota)
/dev/mapper/vg00-mail on /export/mail type ext3 (rw,nosuid,nodev,usrquota)
-----

everything is set up in NIS to provide consitency across systems:

-----
gruizade at csefast(pts/19):~ 23 > ypmatch gruizade passwd
gruizade:x:XXX:YYY:Gregory Ruiz-Ade:/home/gruizade:/bin/tcsh
gruizade at csefast(pts/19):~ 24 > ypmatch -k gruizade auto.home
gruizade csefast:/export/homes1/&
-----

and automounter (autofs) is used to put things where they're supposed to be 
when a user (or a user's process) needs access:

-----
gruizade at csefast(pts/19):~ 26 > mount | grep auto
automount(pid2449) on /home type autofs 
(rw,fd=5,pgrp=2449,minproto=2,maxproto=4)
-----

the automounter on Linux is apparently smart enough to realize when you're 
telling it to mount a local filesystem over NFS, and simply bypasses NFS by 
using a bind mount.  So, when I log in to the NFS server, instead of doign 
an NFS mount, it does a bind mount:

-----
gruizade at csefast(pts/19):~ 27 > mount | grep gruizade
/export/homes1/gruizade on /home/gruizade type none (rw,bind)
-----

So, yes, while the filesystem is exported via NFS, and other systems are 
accessing the filesystems via NFS, the only thing touching the mail files 
should be sendmail, procmail, or dovecot running on the server itself.

Gregory

-- 
Gregory K. Ruiz-Ade
Sr. Systems Administrator
Computer Science and Engineering
University of California, San Diego
Office: EBU3b 1216
Phone:  (858) 822-2625
E-mail: gkra at ucsd.edu