fsync(2) weirdness

Scott Laird (laird@pacificrim.net)
Thu, 02 Oct 1997 14:45:53 -0700


Can someone explain this ('strace -r -T' output, showing relative
times on the left and total time spent in the syscall in brackets on
the right):

0.000000 lseek(4, 8192, SEEK_SET) = 8192 <0.000347>
0.030219 write(4, "\10\2\23\0 \0\0\2"..., 8192) = 8192 <0.019031>
0.019484 fsync(4) = 0 <100.531970>
100.532680 lseek(4, 1420918784, SEEK_SET) = 1420918784 <0.000105>
0.000325 read(4, "\6\0\23\0\0\346\01644"..., 8192) = 8192 <0.014335>
0.014785 lseek(4, 1421033472, SEEK_SET) = 1421033472 <0.000093>
0.000298 write(4, "\4\2\23\0\0$\1\0\377"..., 8192) = 8192 <0.000336>
0.000633 fsync(4) = 0 <103.124272>
103.125032 lseek(4, 0, SEEK_SET) = 0 <0.000107>
0.000327 write(4, "\10\2\23\0\0\231&\0"..., 8192) = 8192 <0.000306>
0.000657 fsync(4) = 0 <100.614055>
100.614814 lseek(4, 8192, SEEK_SET) = 8192 <0.000107>
0.000328 write(4, "\10\2\23\0\0\231&\0\0"..., 8192) = 8192 <0.015218>

Why is Linux spending ~100 seconds to sync 8k worth of data? This is
under 2.1.55 on a P6/200 with 128 MB of RAM and two 7200 RPM SCSI
drives. The system is otherwise idle.

I'm going to drop back to 2.0.x in a couple hours and see if it makes
a difference in the fsync times. I sort of doubt it will, though,
because the application (the Solid database server) performed
similarly under 2.0.x, and we upgraded to 2.1.x in an attempt to fix
the problem...

Scott