toasters

toasters@lists.teaparty.net

1 participants
13518 discussions

Start a nNew thread

Subscribe
by Matthew J. Howarth 07 Jul '97

07 Jul '97

1 0

Re: Filers for a large mail environment
by Edward Henigin 04 Jul '97

04 Jul '97

I wanna talk this out. What do you mean about "100,000 files in a directory will cause you performance problems"? I was told by Network Appliance that their WAFFLE filesystem (or whatever) hashes the directory entries internally, so there are *no* scaling issues with regards to directories with many entries in them. Are you wrong? Or is Network Appliances wrong? Please help. Ed Henigin ed(a)texas.net ps just what the heck do you mean by 'setting up a directory hashing scheme' ? Are you talking about the MTA and/or POP3 servers having their own databases of filename->inode mappings? Your terminoligy seems vague, maybe that's where my confusion stems. -- ---------- Forwarded message ---------- Date: Wed, 02 Jul 1997 17:54:13 +0100 From: Dom Mitchell <hdm(a)demon.net> To: Alan Judge <Alan.Judge(a)indigo.ie> Cc: toasters(a)mathworks.com Subject: Re: Filers for a large mail environment [...deletia...] Shared maildrops are a different issue. If you use something like qmail[1], OTOH, there are simply no locking issues whatsoever (and easy POP3 support, but no IMAP). We do something similiar (although propietary) for about 100,000 users, and it works well. Don't ^^^^^ forget to set up a directory hashing scheme, though as 100,000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ files in a directory will also cause you performance problems. :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Dom [1] <URL:http://www.qmail.org/> -----End of forwarded message-----

9 11

Re: [sm_recover] error messages
by Amy Chused 03 Jul '97

03 Jul '97

At 10:57 AM 7/3/97 -0400, Christoph Doerbeck wrote: >> The filers try to save state so they know what machines are clients of theirs. >> Go ahead and blow away the /etc/sm/recover and/or the /etc/sm/state files. >> It doesn't hurt the filer; the filer will regenerate those files when it >> needs them, but it'll get rid of the error messages from the filer trying >> to talk to machines that don't exist anymore. >What you say makes sense, but the only files in /etc/sm are : state,monitor, >and notify. I tried moving /etc/sm/state but the messages are still coming. My apologies. It was an off-the-cuff answer. I should have said notify when I said recover. (I'm working on setting up a backup system here, so I've got recover on the mind). It's definitely safe to blow away the notify file. >Is it safe to remove all files in the /etc/sm directory? I belive so. >The F330 is running version 3.1c mm-hmm. I've run just about all the versions since 2.something-early, up to 4.0.1c. 3.1c is pretty good. Amy

1 0

Re: [sm_recover] error messages
by Amy Chused 03 Jul '97

03 Jul '97

At 08:11 AM 7/3/97 -0400, Christoph Doerbeck wrote: >Could anyone shed some light on what is generating the following messages >on one of our netapp F330's: > >[sm_recover]: get RPC port for <host=machinea.foo.com,prog=100024,ver=1,prot=17 >> failed >[sm_recover]: no address for host <machineb.foo.com> > >The listed machines were recently taken out of service or moved to another >network. Any opions are welcome... The filers try to save state so they know what machines are clients of theirs. Go ahead and blow away the /etc/sm/recover and/or the /etc/sm/state files. It doesn't hurt the filer; the filer will regenerate those files when it needs them, but it'll get rid of the error messages from the filer trying to talk to machines that don't exist anymore. Amy

2 1

[sm_recover] error messages
by Christoph Doerbeck 03 Jul '97

03 Jul '97

Could anyone shed some light on what is generating the following messages on one of our netapp F330's: [sm_recover]: get RPC port for <host=machinea.foo.com,prog=100024,ver=1,prot=17 > failed [sm_recover]: no address for host <machineb.foo.com> The listed machines were recently taken out of service or moved to another network. Any opions are welcome... ++-------------------------------------------------------------------- Christoph Doerbeck Motorola ISG email: doerbeck(a)dma.isg.mot.com Mansfield, MA. USA ++--------------------------------------------------------------------

1 0

Re: Filers for a large mail environment
by Alan Judge 03 Jul '97

03 Jul '97

Dom> It all depends on whether you mean "shared mail queue" or "shared Dom> maildrops"... Sharing the mail queue is a big nono, really. Dom> None of the existing MTA's support doing this, and it will cause Dom> you slow mail delivery and general havoc. Shared maildrops and home directories is what I'm looking for. I'm planning to leave the mail queues on the individual machines, though a combined view of everything would be nice. (Actually storing each machine's queue (separately) on the filer might be nice for reliability and management reasons. I'm not sure about performance.) Dom> Shared maildrops are a different issue. If you use something Dom> like qmail[1], OTOH, there are simply no locking issues Dom> whatsoever (and easy POP3 support, but no IMAP). I'll have another look at qmail, but we're pretty firmly entrenched in the sendmail camp at the moment, for a variety of reasons. Dom> Don't forget to set up a directory hashing scheme, though as Dom> 100,000 files in a directory will also cause you performance Dom> problems. :-) I'll probably do this anyway while switching over. We don't have enough files now to be much of an issue on a WAFL file system, but we might as well put in the scalability now. -- Alan

2 1

Re: Filers for a large mail environment
by Alan Judge 03 Jul '97

03 Jul '97

Joel> My understanding is that even with nfs locking having multiple Joel> systems do delivery is not safe. Probably, though having one delivery system and multiple POP/IMAP system might be nearly as bad. It depends. Joel> Could you live with a single (+ backup) delivery system? Having Joel> several MXs of different preferences should be ok as I would Joel> expect only one to actually be delivering mail at any time. Probably. We'll have to test performance for this setup. -- Alan

1 0

NetApp Errors
by John F. Kane 02 Jul '97

02 Jul '97

Has anyone experienced any of the following errors on their F330 (or any other) filer running Release 4.0.1c? 1.) Unexplained reboots 2.) portmapper errors-> [portmapper]: portmap: prog (100004,2,2) not registered 3.) rsh hangs -> "system hung (rshd_0)!" 4.) machine check -> MACHINE CHECK: addr 0037470c,mctd,PCMC ERRSTS 8 5.) crash -> "trap 13 code=0 eip=20625f cs=8 eflangs=10202" Any help would be appreciated. -- John F. Kane Joint Analysis Center, EUCOM The MITRE Corporation

2 1

Filers for a large mail environment
by Alan Judge 02 Jul '97

02 Jul '97

We're considering purchasing filer(s) as part of a mail system upgrade. Setup would be a cluster of redundant and very similarly configured machine around one or more filers containing all the real data (/var/spool/mail for customers, some web serving, and other stuff). Most likely all the clustered machines will do delivery to the shared area and POP/IMAP reading. Our desired platform is PCs running FreeBSD (or perhaps BSDI). One major problem is that none of the PC Unix environments (FreeBSD, BSDI, Linux) have working NFS file locking. We could implement some hacks using file based locking, but I'm worried about the hassle and performance issues here. In fact, even with working NFS locking, I'd be worried about sharing mail spools in this fashion. I've also had advice from people who recommend avoiding NFS entirely and going for transparent proxies and multiple machines for scalability. But that leaves a reliability/redundancy issue (hardware RAIDs, s/w mirroring, ...). What I'm wondering and perhaps people on the list can help is: - anyone doing something similar in an ISP environment (what platform, what filer, how many users?) - any advice/ideas on the locking issue - will filers perform well in this environment? some of the client applications are not well behaved and do things like copy the entire mail box; local disk would obviously be faster (I can get over 35MB/sec using multiple local disks on PCs), but I'm not sure it's that big an issue -- Alan Judge Phone: +353-1-6046901 Indigo Network Operations Centre Fax: +353-1-6046948

4 3

archive
by Tom Yates 02 Jul '97

02 Jul '97

i'm getting a report that the archive is impossible to get to. can anyone who has experienced problems in getting to the toasters archive (http://teaparty.mathworks.com:1999/toasters/archive/) let me know? thanks. Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C "Microsoft (tm) is a single-sofa supplier"

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters