Mailinglist Archive: opensuse (1239 mails)

< Previous Next >
Re: [opensuse] Re: XFS and openSUSE 12.1
  • From: Roger Oberholtzer <roger@xxxxxx>
  • Date: Tue, 11 Jun 2013 14:15:13 +0200
  • Message-id: <1370952913.2020.72.camel@acme.pacific>
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@xxxxxxxxxx
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread