-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Peter Kjellstrom Sent: Wednesday, March 21, 2007 11:51 AM To: centos@centos.org Subject: Re: [CentOS] Kernel question(s): I/O handling
I hope some of that made sense :-)
Actually, yes, thanks.
Now the big one - please verify if you can (anyone).
As I read the source, it appears that the page cache is flushed one page at a time, regardless of any kind of order of flushing that might optimize the throughput. Not only that, the superblocks get flushed in the same order every time, assuming that there are no mount changes and the superblock queue remains constant.
I saw no markers to indicate to whoever happens to be doing the cache flush at the time to pick up at a later point (i.e., continue where it left off on the last flush), which means that a really busy file system near the head of the queue can cause i/o problems with all file systems (superblocks) behind it. Even if one increases the count and range of pdflush processes, this would be more or less true (although, admittedly, the head FS would have to be REALLY busy to do this).
Unfortunately, that is our situation - we work the file systems to death, almost, by doing huge i/os (like 100Mb+ at a time) in sequential order in the various files, with more than one such transaction likely to be occurring concurrently, hopefully on more than one disk.
This would explain the first question I asked here: why the page cache is so much slower than direct i/o for huge i/os.
(Wait - does this mean that if I stick around long enough and keep digging on my own, I'll find all the answers to the questions that no one else has? Heavens to murgatroid! :-)
mhr