>> ...I also removed some unnessecary fsync()s as they were
>> slowing down everything very much...
> Be careful; if you mean that you've removed fsync()s from Dan's code,
> then you have definitely thrown away reliability in order to gain
> throughput. In your application, is it acceptable for emails to be
> silently lost under a power failure? Where did you get the idea that
> they were "unneccesary"?
> BTW you could get the same result--indeed, better results--without
> tampering with Dan's code, if you simply add memory and mount a
> ramdisk on /var/qmail/queue.
> If that revolts you, then you might want to put the fsync()s back.
>> ..IO is obviously the problem here, not how-to-interpret-that
>> damn-uptime-load...
> Correct. But Dan is not stupid; when he accepted the I/O cost, it was
> to gain a benefit. Before you refuse the cost, you should be sure you
> know what the benefit was--and that it doesn't outweigh the cost.
Ok firstly,
Who said I removed fsync()s from Dan's code? Please read my
closing and see if I've said that. You see, you're really
taking words out of my mouth.
What I said was that I removed unnessesary fsync()s. From *MY*
code, that is. I used two fsync()s before every close, just to
reassure that we wouldn't get any NFS problems. Now, we aren't
ever going to run NFS, so I removed *one* fsync per file-close
and wrote it as a 'fdatasync'. Our RAID-7 controller is mounted
with write-through cache and so the loss of mails equals ZIP.
First, you complain about my where-did-you-get-that-from removing
of Dan Bernstein's fsync()s, then you advise me to mount my
queue-directory on a *ramdisk*????
That means, if the power dies and the UPS short-circuits, all
the mail in the queue will be lost!
Andreas
