From owner-freebsd-net@FreeBSD.ORG Tue Apr 5 16:55:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DBBD1065676 for ; Tue, 5 Apr 2011 16:55:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 534B88FC18 for ; Tue, 5 Apr 2011 16:55:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJ600IPZUZMMX70@asmtp023.mac.com> for freebsd-net@freebsd.org; Tue, 05 Apr 2011 09:54:59 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-05_08:2011-04-05, 2011-04-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104050110 From: Chuck Swiger In-reply-to: <4d9acc53.w52H7UX61+6sZ3rH%perryh@pluto.rain.com> Date: Tue, 05 Apr 2011 09:54:58 -0700 Message-id: <9708F193-E78D-4B26-A4F9-A2CBCC1D90CE@mac.com> References: <1359778820.2757108.1301963093210.JavaMail.root@erie.cs.uoguelph.ca> <4d9acc53.w52H7UX61+6sZ3rH%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1084) Cc: freebsd-net Net Subject: Re: 7-STABLE NFS: fatal: "select lock: Permission denied" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:55:00 -0000 On Apr 5, 2011, at 1:01 AM, perryh@pluto.rain.com wrote: > Chuck Swiger wrote: > >> It's fairly common to scale up a mail infrastructure from one box >> handling both SMTP and IMAP (or POP) to a SMTP-only box writing to >> NFS-mounted user mailboxes, and have one or more dedicated reader >> boxes which only run IMAP/POP daemons which access that same NFS >> filesystem holding the user mailboxes. > > Yikes! The _proper_ way to scale up from one box to multiple goes > something like this: [ ... ] > mail. becomes a multiplexer, so that the outside world can > send to @mail. (or simply @ if you > prefer) without needing to know about the internal structure. The > multiplexing can be very simple, and thus very fast, by doing a > table-lookup based on the first character of . There's no > need for NFS anywhere in the setup. The problems with this are that each individual reader box has no failover capabilities if something goes down (although you can have standbys and restore from backups), and the convention for allocating the pool of users onto boxes is relatively static, which means you don't distribute clients evenly onto the servers to even balance load as that changes dynamically over time. Growing a mail infrastructure from one to two to many boxes is complex. People tend to take advantage of the resources they have; if you have an EMC or NetApp filer handy, it's might well be reasonable to use it, especially if you can run with a mailbox format that doesn't require NFS locking. Regards, -- -Chuck