User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 In the 1.2 nightlies, mail now does frequent fsyncs during certain operations. For some operations, this may be a reasonable tradeoff between data integrity and performance. For others, however, the fsyncs are just slowing things down. For example, consider the following strace output during a large folder search: Under 1.2b strace shows: lseek(25, 0, SEEK_CUR) = 20999303 lseek(25, 0, SEEK_CUR) = 20999303 lseek(25, 0, SEEK_END) = 65736582 lseek(25, 20999303, SEEK_SET) = 20999303 lseek(25, 20998865, SEEK_SET) = 20998865 lseek(25, 0, SEEK_CUR) = 20998865 read(25, "kIMIlYRMnzBA5whQg/x80wUA24TMNgkR"..., 511) = 511 lseek(25, 0, SEEK_CUR) = 20999376 lseek(25, 0, SEEK_CUR) = 20999376 lseek(25, 0, SEEK_END) = 65736582 lseek(25, 20999376, SEEK_SET) = 20999376 lseek(25, 20998938, SEEK_SET) = 20998938 lseek(25, 0, SEEK_CUR) = 20998938 read(25, "u+NAfSXQ266lso2FQSSkgjykxjkzn+Hj"..., 511) = 511 lseek(25, 0, SEEK_CUR) = 20999449 lseek(25, 0, SEEK_CUR) = 20999449 lseek(25, 0, SEEK_END) = 65736582 lseek(25, 20999449, SEEK_SET) = 20999449 lseek(25, 20999011, SEEK_SET) = 20999011 lseek(25, 0, SEEK_CUR) = 20999011 read(25, "0rIJMcEifFwVHBnApy1W+3claAO+IKiS"..., 511) = 511 With the nightlies, I see: read(31, "Right. I think we started with "..., 511) = 511 fsync(31) = 0 lseek(31, 0, SEEK_CUR) = 11154445 lseek(31, 0, SEEK_CUR) = 11154445 lseek(31, 0, SEEK_END) = 65736582 lseek(31, 11154445, SEEK_SET) = 11154445 lseek(31, 11154007, SEEK_SET) = 11154007 lseek(31, 0, SEEK_CUR) = 11154007 read(31, "didn\'t see anything that looked "..., 511) = 511 fsync(31) = 0 lseek(31, 0, SEEK_CUR) = 11154518 lseek(31, 0, SEEK_CUR) = 11154518 lseek(31, 0, SEEK_END) = 65736582 lseek(31, 11154518, SEEK_SET) = 11154518 lseek(31, 11154075, SEEK_SET) = 11154075 lseek(31, 0, SEEK_CUR) = 11154075 read(31, "\n> Given your suggestion, I mi"..., 511) = 511 fsync(31) = 0 lseek(31, 0, SEEK_CUR) = 11154586 lseek(31, 0, SEEK_CUR) = 11154586 lseek(31, 0, SEEK_END) = 65736582 lseek(31, 11154586, SEEK_SET) = 11154586 lseek(31, 11154076, SEEK_SET) = 11154076 lseek(31, 0, SEEK_CUR) = 11154076 The useless fsyncs cause a tremendous slowdown (not only due to the significant cost of the sync itself, but also because fsync must flush out even the atime). If you absolutly *must* sync (hopefully not), at least fdatasync. With the current behavior, searching a large folder is nearly unusable. Reproducible: Always Steps to Reproduce: 1. 2. 3.

By the way, I'm using Red Hat 7.3 with the 2.4.18-17.7.xsmp errata kernel.

already fixed; please upgrade to a newer trunk build. Sorry about the bug. One benefit of upgrading to a trunk build is that body search doesn't lock up the UI either. *** This bug has been marked as a duplicate of 180516 ***

marking verified as a duplicate