[Barry Warsaw] > Except that when I did some very simple tests, I saw a 97% hit in > performance with fsync turned on.
Ouch. That's pretty severe, all right. Even though I would *guess* that most "casual" Mailman sites would pull through an effective halving of performance without any problems, that is merely a guess... thus, I'm not at all sure that set of sites that would be in trouble with such a big performance hit is disjoint from the set of sites that don't read upgrade documentation very carefully. > This on a RH9, ext3 Linux box of the Dell Optiplex variety. That > makes me very nervous to add in a patch release that won't have any > beta testing. I hadn't considered the "no beta testing" part of this. Reconsidering now, I agree that such a big performance hit in a "bugfix" release ought to be the cause of quite a bit of nervousness on behalf of the release issuer... :-) > I'm happy to re-address this for the next major release, but for > 2.1.3 I don't want to enable fsync by default, and I definitely > don't want to do any probing/guessing of filesystems, etc. That sounds like a good plan to me. However, I'm not sure I understand why this shouldn't be configurable in mm_cfg; is that just to keep the number of configurable variables down? FWIW, PostgreSQL exposes an "do fsync(2)" option in it's global config file; on my Debian system, the option is preceded with this comment: # A special note on FSYNC: # FSYNC only affects writes to the WAL (Write-Ahead Log). Turning it # off will give some increase in performance, but at the risk of data- # corruption in the event of power failure or other disaster. It is on # by default. I strongly recommend you not to turn it off. -- Harald _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
