Rogier Wolff - 05.09.18, 10:04: > On Wed, Sep 05, 2018 at 09:39:58AM +0200, Martin Steigerwald wrote: > > Rogier Wolff - 05.09.18, 09:08: > > > So when a mail queuer puts mail the mailq files and the mail > > > processor can get them out of there intact, nobody is going to > > > notice. (I know mail queuers should call fsync and report errors > > > when that fails, but there are bound to be applications where > > > calling fsync is not appropriate (*)) > > > > AFAIK at least Postfix MDA only reports mail as being accepted over > > SMTP once fsync() on the mail file completed successfully. And I´d > > expect every sensible MDA to do this. I don´t know how Dovecot MDA > > which I currently use for sieve support does this tough. > > Yes. That's why I added the remark that mailers will call fsync and > know about it on the write side. I encountered a situation in the > last few days that when a developer runs into this while developing, > would have caused him to write: > /* Calling this fsync causes unacceptable performance */ > // fsync (fd); Hey, I still have # KDE Sync # Re: zero size file after power failure with kernel 2.6.30.5 # http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/30512 export KDE_EXTRA_FSYNC=1 in my ~/.zshrc. One reason KDE developers did this was Ext3 having been so slow with fsync(). See also: Bug 187172 - truncated configuration files on power loss or hard crash https://bugs.kde.org/187172 > But when apt-get upgrade replaces your /bin/sh and gets a write error > returning error on subsequent reads is really bad. I sometimes used eatmydata with apt upgrade / dist-upgrade, but yeah, this asks for trouble on write interruptions. > It is more difficult than you think. Heh. :) Thanks, -- Martin
