IIRC, fsync() worked by checking to see if any of the blocks associated
with a file were both in memory and dirty - writing them to disk where
necessary. The detail of the problem was that _every_ hash bucket was
populated so we had to walk down a linked list looking for each block in
the file. Most of the time we walked down the list to the end only to
discover that the block was, after all, not in memory. Increasing the
size of the buffer cache's hash table dramatically shortened the length
of the linked lists and helped a great deal.
Based on our experience with 2.2.1, this problem is no longer a
mis-feature of the kernel. From memory (I've not got any notes) I think
the place to look is in linux/fs/buffer.c, the HASH_PAGES value is needs
to be increased (128 might be a good thing to try). You might double
check that this does not have some undesired side effect with the
kernel's memory allocation.
#define HASH_PAGES 4 /* number of pages to use for the hash
table */
Cheers
Andrew
(peeter joot) wrote:
>
> We noticed this too, but got no responses about it.
>
> Even if we haven't actually modified the file in any way (ie: open/seek/read/fscync/close) there are stalls at the fsync stage.
>
> I don't have any of the stats handy. I was told that it wasn't as bad on
> 2.1, but was still way slower than on any other UNIX we have db2 ported to.
>
> Peeter
> --
> Peeter Joot peeterj@ca.ibm.com
> IBM DB2 Operating System Services 416-448-3359 (tie line 778)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/