182080 - Some mail operations very slow due to excessive fsyncs

Status: VERIFIED DUPLICATE of bug 180516

(MailNews Core :: Database, defect)

Description

[Jeffrey Siegal]

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.

Comment 1

[Jeffrey Siegal]

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

Comment 2

[David :Bienvenu]

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 ***

Comment 3

[laurel]

marking verified as a duplicate