The thing about filesystems, and how dimmly MTAs (should) consider
some performance tweaks is something I have tried to describe at
ZMailer's manual in part about its the queue:
http://www.zmailer.org/zman/zadm-queues.html
On Tue, Jul 31, 2001 at 01:25:06AM -0400, Lawrence Greenfield wrote:
...
> It's not as good as fsync() just doing what it's suppose to do.
> You'll force applications that want to issue multiple link()s to issue
> multiple lsync()s, forcing the kernel to serialize all of the disk
> writes when the application just wants one file (and all of it's
> associated filenames) to disk.
>
> Yes, I understand that implementing fsync() so that it syncs all names
> to reach the file is difficult. But if you want the best performance,
> you don't want to make applications issue multiple calls each of which
> force their own synchronous writes.
>
> Not to mention us whiny application writers won't be happy throwing
> lsync()s all over the place.
>
> Larry
I quite agree.
Filesystems are not, unfortunately, rollbackfull logged and committable
databases, even if we like to use them often in that way.
An MTA with a fundamental design point of not using any privileged
programs (no suid anything!) and least esoteric technology possible
(for wide portability) can only use message submission means available
to it everywhere -- implementing the queue inside a database system
is definitely a possibility. Possibly yielding higher performance
than one using filesystem for it, but at what cost ??
(I am thinking of SleepyCat DB multiaccess transaction supported
version.)
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:51 EST