[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Version 2.99.7 is out
Tom Samplonius wrote:
> At 09:14 AM 1/2/95 +0200, Matti Aarnio wrote:
> > Yes, I did get a report that patching from 2.99.3 to ..6 was not
> > completely successfull, so I was not sure if it would succeed.
> > (Basically the code that was moved to fdstatfs.c was not removed
> > from smtpserver.c itself for some reason...)
>
> Hmm, I better check smtpserver.c, but I didn't have any problems
> compiling except for that seq_remap thing.... is the mmap stuff
> recommended? I seem to recall a define that resulted in the seq_remap
> function being ifdef'ed out...
IMO yes. It is a performance issue, and can be of benefit
when the routers have to do lots of address lookups from
ordered files (sort(1) ordered, that is..)
The seq_remap() proved to create more syscalls (fstat()s)
than I had wished for, thus I do recommend of using "-m"
on the relation definition, and no seq_remap().
Having the fstat() there triggering the remap got me three
fstat() calls for one lookup of routes file. Without the
seq_remap(), but with "-m" it gets one.
(Well, fstat() is a lot more light-weight than read() which
are plentyfull without the mmap()..)
> > Are you sure your patch won't break BSDI ?
> > I was not quite sure, so I didn't introduce it.
>
> Pretty sure, BSD4_4 is defined on bsdi (according to what someone on this
> list said) in param.h, so changing the ifdef's around the includes in
> smptserver.c, to BSD4_4 shouldn't be a problem. And my 4.4BSD Programmer
> Reference says that fstatfs returns a struct with f_bsize and f_bavail
> fields, so the #if define(__linux__) || (defined(BSD4_4) && !defined(bsdi))
> should take care of linux and 4.4bsd systems except for bsdi which gets
> handled later. (I've attached a patch from 2.99.6)
Ok, I will include it.
> > On overall I think the service could use the code used on
> > GNU fileutils "df", but it calls for complete rewrite of
> > the configuring mechanism...
>
> It seems that every vendor has made their "df" produce a different output
> format. However, you could borrow the strategy from innwatch (from INN) of
> using a user definable shell script to parse the output of df.
Naeh, unnecessary context-switches for it.
Sharing code with GNU-fileutils is better approach :-)
> > /Matti Aarnio <mea@utu.fi>
...
> ---
> UNIServe Online
> tom@haven.uniserve.com
> http://www.uniserve.com
/Matti Aarnio