From owner-freebsd-questions@FreeBSD.ORG Fri May 16 13:38:23 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4711937B401 for ; Fri, 16 May 2003 13:38:23 -0700 (PDT) Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 787D843F3F for ; Fri, 16 May 2003 13:38:22 -0700 (PDT) (envelope-from aaron@justaaron.com) Received: from justaaron.com (dsc02-ari-co-4-74.rasserver.net [204.32.207.74]) by deimos.frii.net (8.12.9/8.12.9) with ESMTP id h4GKcLa3011982 for ; Fri, 16 May 2003 14:38:21 -0600 (MDT) Message-ID: <3EC54C38.4010005@justaaron.com> Date: Fri, 16 May 2003 14:38:16 -0600 From: Aaron User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: mail access to second disk slow X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: aaron@justaaron.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 20:38:23 -0000 Someone replied offline, my attempts to follow his suggestions, plus more data: > 'Tis DOS, I think. The WNT disk is FAT and BSD's FAT code isn't exactly > fast. My guess is that imap is relying on some underlying UNIX-ism in > the filesystem, and the BSD DOS layer has to emulate it using some > really lame algorithm and/or file copying. More data: To date, I have tried: - MozillaMail via Imap to my bsd disk (great) - MozillaMail via Imap to my W2K disk (sux) - Pine via Imap to my bsd disk (great-ish) - Pine via Imap to my W2K disk (sux) - Pine directly to the mbox folders on my W2K disk (sux) Note that both Pine and imap-uw (the imap I'm using) are produced by the University of Washington, and both use the cclient utilities, also produced by the U of W. Which may explain why Pine directly to mbox folders sux. I got the bright idea of using mailx -f /one/of/my/w2k/folders, and the response was *immediate*. I seriously doubt mailx knows what cclient is. So, it is possible to access w2k folders quickly, either by catting them, or using mailx. So I'm guessing it's not DOS, and may well be cclient or some related culprit. > Run "top" (or "top -I") while accessing your mailbox and see if the CPU > is spiking up. Similarly, check the disk access lamp, or use iostat etc > to see what's happening during the FAT accesses. I did this with MozillaMail via Imap to my w2k folders. CPU seemed to go up 10 or 20%, and MozillaMail rose to the top of the % of usage, meanwhile I'm just hanging there waiting. imapd stayed at zero the whole time I was waiting (minutes). Finally the folder listed its messages, and imapd briefly climbed to 2nd or 3rd place, then dropped back down into oblivion and from that point on I can access the folder fine. Until I try the next folder, same scenario. Similar with Pine direct to w2k folders (no imap), a long wait, but only few % rise in CPU. After the long timeout, Pine rose to 2nd or 3rd % place, the folder listed and Pine dropped back down. I didn't bother topping in a mailx scenario. > Search the FreeBSD mail archives for FAT filesystem info. I think that > the code isn't too robust but that may have been fixed. A long while > ago, the recommendation was to avoid leaving things mounted as FAT due > to a variety of problems. Searched -questions in the old and new archives, didn't find anything particularly pertinent. I wonder if DOS/FAT/cclient in 5.X hold improvements to look forward to? Although I *really* wonder/hope is there something that can be done in 4.8? Would anyone recommend one of the other imap servers? Remember, this is for internal service on a 2 box lan, no external mail serving, so it should be fairly simple to administer and lightweight-ish. Also, it should be able to use mbox folders, so I can preserve the ability to access them directly as described above. Thanks. aaron