> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
> Behalf Of Peter Kjellstrom
> Sent: Wednesday, March 21, 2007 11:51 AM
> To: centos@xxxxxxxxxx
> Subject: Re: 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
