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@csefast(pts/19):~ 23 > ypmatch gruizade passwd gruizade:x:XXX:YYY:Gregory Ruiz-Ade:/home/gruizade:/bin/tcsh gruizade@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@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@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@ucsd.edu