Re: hardware sizing ?
henning, all, > > > It's a matter of fact that qmail isn't as reliable on Linux as on *BSD as it > > > relies on some FFS semantics ext2fs just doen not fulfill. > > If that is the case then there is a bug in qmail - the software should > > be correct to the system underneath it, not apply semantics that aren't > > supported and say "it's their problem, not ours...!" when it doesn't > > work properly. > > No, it's a bug in ext2fs. that's crap, of course. if it's a bug in ext2 then it's a bug in softupdates and large numbers of other filesystems that don't provide syncrhonous metadata updates by default (although all of them do and can). there has just been a long discussion about exactly this issue on the linux kernel mailing list, specifically whether the SUS (single unix specification) requires than an fsync also synch a directory tree up to the root before returning. the conclusion of many people on the lkml (including those advocating the behavior) is that SUS does not require this behavior although it would be nice to offer an ext2 or vfs option for supporting it. people also noted that linux uses the semantics of fsync(dir) to synchronize the name metadata for a file and that that is fast and efficient (as others have noted, ext2 also offers the option of mounting filesystems and directories in synchronous mode, but that slows down everything of course). a patch to make qmail fsync the parent directory has been around for a long time and causes qmail to behave reliably (and fast!) on linux. the bottom line is that FFS semantics are not universal and they haven't been for a long time, even among bsds. assuming that they are is a mistake. todd underwood vice president & chief technology officer oso grande technologies, inc. [EMAIL PROTECTED]
Re: deleting messages from the queue
dave, all, > "It's ridiculous because if pigs had wings, they could fly." > > Pigs don't have wings, and qmail-smtpd can't do the lookups. You > either need to stop wishing your pig could fly or trade it for a bird. > this comment has the obviously unintended and unfortunate side-effect of implying that qmail is a pig and other, less-well-written, MTAs are more like birds. :-) that can't be what you intended. todd underwood vice president & chief technology officer oso grande technologies, inc. [EMAIL PROTECTED]
Re: /var partition, queue size, and sendmail
joshua, you're probably not going to like my answer (since it is one of those 'do lots of work now for less work later' options), but we use logical volume managers on most of the production systems around here. you didn't say what operating system you're using but AIX, HPUX, Solaris and now even linux (with the Linux LVM project at sistina.com and now the EVMS port of AIX's excellent LVM to linux as well at sourceforge.net/projects/evms). all of these solutions allow a properly-prepared filesystem (in linux ext2 and reiser can both apply) to be resized as the underlying logical volume is increased in size. once you go down this route, you'll never want to go back to static, bios-based partitions. anyway, this doesn't solve your problem in the short run, but it would have solved your problem if you'd gone this direction several months ago (ach, the irony!). todd underwood vice president & chief technology officer oso grande technologies, inc. [EMAIL PROTECTED] On Wed, 30 May 2001, Joshua Nichols wrote: > Date: Wed, 30 May 2001 09:02:22 -0400 > From: Joshua Nichols <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: /var partition, queue size, and sendmail > > I recently discovered that my /var partition is not going to be large enough > to accomodate my queue at certain times, and was hoping for some insight. > > As a temporary fix, I moved the queue to another partition (/home of all > places) and created a symbolic link. I realize that there are some security > concerns with this solution, so I am seeking advice. Is there a > (reasonably) safe utility to resize my partitions without starting over > (which is not really an option)? Is there another acceptable place to store > the queue? And if so, is a symbolic link acceptable, or should I recompile > to reflect the new queue location? Are there performance concerns here? > Here's my partition table, and the output of 'df' for your consideration. > The system is RedHat 7.0. > > partition table: > Disk /dev/sda: 255 heads, 63 sectors, 2202 cylinders > Units = cylinders of 16065 * 512 bytes > >Device BootStart EndBlocks Id System > /dev/sda1 * 1 3 24066 83 Linux > /dev/sda2 4 2202 17663467+ 5 Extended > /dev/sda5 4 1002 8024436 83 Linux > /dev/sda6 1003 2001 8024436 83 Linux > /dev/sda7 2002 2034265041 83 Linux > /dev/sda8 2035 2067265041 83 Linux > /dev/sda9 2068 2100265041 82 Linux swap > > df: > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/sda8 256667243418 0 100% / > /dev/sda123302 9106 12993 42% /boot > /dev/sda6 7898380 97088 7400072 2% /home > /dev/sda5 7898380 1000684 6496476 14% /usr > /dev/sda7 256667 57363186052 24% /var > > The cause of the large queue is a mailing list that sends about 150,000 > messages at 10-25k per message once a week (via qmail's replacement for > sendmail), so I figure I'll bring up the large queue problem as well. I > know this borders on an FAQ, but what I'm not sure of is this--is there > /any/ way to avoid the queue size limit of 20ish thousand messages? As I > understand it, the big-todo patch doesn't actually solve it, it just splits > up the todo directory, and conf-split is only able to increase performance. > Please tell me I'm wrong, because I'm not /positive/ that this will be an > avoidable problem in the future. > > Thanks to everyone for any suggestions they can offer. > > > --joshua. > > >
Re: Maildir-Aware /bin/mail Replacement?
kai, why not just use procmail? many people use procmail as a sendmail local delivery agent anyway (security be damned! you're running sendmail anyway so how much could you possibly care?). procmail talks native maildirs for some time now. Todd Underwood Chief Technology Officer Oso Grande Technologies, Inc. [EMAIL PROTECTED] On Mon, 23 Oct 2000, Kai MacTane wrote: > Date: Mon, 23 Oct 2000 11:19:53 -0700 > From: Kai MacTane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Maildir-Aware /bin/mail Replacement? > > Hello. Does anyone know of a Maildir-aware replacement for /bin/mail, or a > patch that will give it Maildir awareness? I've looked at qail, but that > seems to be a simple shell script that runs maildir2mbox on the user's > Maildir and then runs /bin/mail (and then doesn't put messages back into > Maildir format!). This is an unacceptably clunky solution, and one that > really isn't a total solution anyway, considering the problem. > > The problem, really, is that I'd like to allow users to check their mail on > the command line (after ssh-ing in) and/or by POP3. Unfortunately, users > familiar with the command line have a tendency to log in and type "mail" to > see if they have any mail. And a non-Maildir-aware /bin/mail then claims > they have none, ignoring the dozens of files in ~/Maildir/new. > > I have looked on the Qmail site for any such thing, and found nothing. Are > there no Maildir patches or replacements for /bin/mail? It seems that such > a common utility *should* have a Maildir-capable version. (I cannot write > it myself, as I have just barely enough knowledge of C to write a 'Hello, > World!" program.) > > --Kai MacTane > -- > "Playing dead and sweet submission, > Cracks the whip deadpan on cue." > --Siouxsie and the >Banshees, > "Peek-a-boo" > >
