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:04:02 +0200
  • Message-id: <1370952242.2020.61.camel@acme.pacific>
On Tue, 2013-06-11 at 07:36 -0400, Anton Aylward wrote:
Roger Oberholtzer said the following on 06/11/2013 07:16 AM:
* If I close all apps that have a file open on the file system, the
cache use remains.
* If I run the 'sync(1)' command, the cache use remains. I would have
thought that the cache would be freed as there is nothing left to cache.
If not immediately, over a decent amount of time. But this is not the
case.
* Only when I unmount the file system does the cache get freed.
Immediately.

I think you're confusing a cacahe with a write-through buffer.

While *YOU* may know that this is being used in write-only mode, the
system doens't. A cacahe supposes (temporal at least) locality of
access, that the data may be needed again in a short while and that even
if it has been written out (as with 'flush') it may be wanted again shortly.

In addition, what may be cached might not be data, it might be metadata
for the file system.

That an unmount clears the cache makes sense; there is nothing more
wanted with respect to that drive.

https://en.wikipedia.org/wiki/Cache_%28computing%29
<quote>
In computer science, a cache is a component that transparently stores
data so that future requests for that data can be served faster. The
data that is stored within a cache might be values that have been
computed earlier or duplicates of original values that are stored
elsewhere. If requested data is contained in the cache (cache hit), this
request can be served by simply reading the cache, which is
comparatively faster.
</quote>

and
https://en.wikipedia.org/wiki/Cache_%28computing%29#The_difference_between_buffer_and_cache
<quote>
Buffering, on the other hand, a) serves to reduce the number of
transfers for otherwise novel data amongst communicating processes,
which serves to amortize overhead involved for several small transfers
over fewer, larger transfers .....
</quote>

I have no problem with this. I understand the concept of and benefits of
a cache. But what I do not understand is why, as the cache grows
(seemingly out of my control), the amount that waits to be flushed to
the disk grows, making each successive flush take longer. Or at least
this is what it looks like is happening. So, when the OS has obtained,
say, 24 GB of cache, each time it needs to flush it takes longer as
there is so much.

Of course, something else entirely may be happening. But this is what it
looks like to me. I do not know how much of the cache is things that are
not yet physically on the disk. I would like to know how to see that.

I did open the file with O_SYNC. That was not good. The write times,
although perhaps more even, were extremely slow - by a factor of 10 or
so. Which is rather expected as the system is not caching so much.
However, the cache usage still grows the same. It is like there is one
set of logic that only looks at the filesystem write rate and available
RAM and decides to get more. And an independent set of logic that is
flushing as O_SYNC indicates. The former seems 'broken' and the later
seems to work as expected.



--
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
Follow Ups