[34236] in North American Network Operators' Group
Re: Scalable Mail solution with NAS
daemon@ATHENA.MIT.EDU (Neil J. McRae)
Wed Jan 31 16:04:28 2001
From: "Neil J. McRae" <neil@DOMINO.ORG>
Message-Id: <200101312106.VAA29062@equinox.DOMINO.ORG>
In-Reply-To: <20010201041652.H36522@ewok.creative.net.au> from Adrian Chadd at "Feb 1, 2001 04:16:54 am"
To: adrian@creative.net.au (Adrian Chadd)
Date: Wed, 31 Jan 2001 21:06:00 +0000 (GMT)
Cc: mzito@register.com (Matthew Zito), nanog@merit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
> > But, with 200k mailboxes, you should have an automated way to do that anyway.
>
> Hah. Unlink the directory, and do a background fsck every few hours? :)
I don't know why you'd want to do the above, but you could add code
to the deliver agents; When inbound email hits the system: create
the require directories and files if required, this could be
mail.local, deliver or something similar. When mailbox is emptied
get the delivery agent [could be pop3d or imapd] to delete any
empty directories, then growing directories can be kept under
control.
>
> The trouble with the above format is that you're ignoring any locality
> that exists in the filesystem. For example, in Berkeley FFS, files in
> a given directory are allocated in the same cylinder group (or at least
> it is attempted..)
>
> Which, under heavy heavy load could actually give a slight performance
> boost on a non-filled FFS.
Agreed, but depending on the scale you'd most likely want logging file
systems otherwise reboots could be painful.
Regards,
Neil.
