On Tue, 2013-06-11 at 07:48 -0400, Anton Aylward wrote:
Roger Oberholtzer said the following on 06/11/2013 07:16 AM:
Why would the cache grow and grow? Since the delay, when it happens, grows and grows, I get the feeling that this file system cache in RAM is slowly getting bigger and bigger, and each time it needs to be flushed, it takes longer and longer. If the cache is being emptied at some reasonable point, why would it continue to grow? Remember that for each mounted file system there is one process writing to a single file. The disk usage remains 100% constant in terms of what is sent to be written.
Is there some policy or setting that controls how the file system deals with file system cache in RAM? More specifically, is there any way to limit it's size for a file system?
Is there a way to see how much of the RAM cache for a file system is actually containing data waiting to be flushed?
Your problem is that you are treating the cache as a buffer. Yes things get written, but the FS doesn't know you are running in 'write-only' mode so its retailing the most recently written and structural metadata just in case you want to read some if it back.
*THAT* is what a cache is about. Retaining stuff in case you want it again soon.
That you don't, that you are treating the cacche as a buffer and its behaving as a cache, is the root of that you are observing and complaining about.
I am not doing this. I am only reporting that it seems that as the file system gets written to, the OS cache grows and grows. As the cache grows, the occasional flushes that are done to the disk seem to take longer and longer. Coincidence? Perhaps. Repeatable? 100%.
Every now and again the caching algorithm need to 'flush' the 'least recently used' or sync metadata or somehow reorganise, or something, or something like that, depending on the implementation and algorithm.
As an earlier commentator pointed out, whiting to a raw disk avoids this :-)
Perhaps. But I wonder about the performance of the raw disk compared to O_SYNC, where things are also not buffered. Maybe the raw disk is better because only bigger blocks get written to the disk, whereas O_SYNC is at the mercy of each variable sized write(). Sigh. When writing to a disk at < 20% of it's sustained write rate, on a system with many idle cores and lots of ram, you would think that performance would be okay.
Are there ways to control the cache? Probably, but it gets back to my point about you treating the cache as if it was a buffer.
You want buffering but not caching because, as far as I can see, you are doing 'write only'.
There are other factors such as 'commit times' and and matters to do with how the fie system reorgnaizes its b-trees, for example. All these can introduce the delays of which you speak.
-- How long did the whining go on when KDE2 went on KDE3?
The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013
Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org