[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary: Moving /tmp to tmpfs makes it useless



2012/6/10 Uoti Urpala wrote:

>> Yes, I know it was a biased summary. So as yours. But there's a difference
>> between mine and yours. Mine is based on some real-world applications,
>
> You've posted blatantly false claims. If you post claims like "1+1
> equals 2 because the moon is made of cheese", then you're a moron, even
> if 1+1 does equal 2.

(I like this example :)) It could be, it's impossible to know everything
in the world, I can be wrong. What false claim are you talking about?

>> Do you dismiss the theory (confirmed by Uoti Urpala test script) that
>> tmpfs+swap INCREASE number of writes and are hence bad for SSD?
>
> I think what the script shows is that there can be significant problems
> using tmpfs to hold large amounts of data, even if you have a lots of
> swap so that running out is not an issue. It doesn't show that the
> number of writes would increase on average.
>
> In general you seem to be quite clueless about the actual behavior of
> cache/swap, but you've still continued to make various claims about it.

I was referencing your words:

2012/5/25 Uoti Urpala wrote:
> Thus, if you do multiple read iterations through a large set of data
> (which does not fit in memory) on tmpfs, each iteration does disk
> read AND write rather than just read.

2012/6/1 Uoti Urpala wrote:
> I haven't read the relevant kernel code, but that doesn't match the
> behavior I see. Reading a large file from tmpfs and then allocating
> memory results in large swap writes every time, even if the newly
> allocated memory is not itself immediately swapped out and the file
> should already be in swap from before.

Reading from swap generates additional writes. It mean that tmpfs+swap
may actually increase amount of writes instead of reducing it, isn't it?

If you don't want me to reference your words, well, let's recheck that
guess again. Pressing "Enter" on .tar.bz2 archive in mc will untar it
to /tmp, burning a CD may generate iso-image in /tmp, let's check how
many write there would be in case of tmpfs?

Startup conditions:
  # free
               total       used       free     shared    buffers     cached
  Mem:       1017588     850224     167364          0      63332     480588
  -/+ buffers/cache:     306304     711284
  Swap:      2249092      40764    2208328
That is 1GB RAM, 2GB swap, 300MB RAM in use (which is barely enough for
almost empty gnome session), 700MB free. Swap is on /dev/sda3:
  # cat /proc/swaps
  Filename                                Type            Size    Used
   Priority
  /dev/sda3                               partition       2249092 40764   -1
and is almost unused. Initial `iostat -k /dev/sda3` output:
  Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
  sda3              9,70        69,46        80,04     122660     141340
So there were 140MB written yet. Now let's put a 1GB file on tmpfs:
  # dd if=/dev/zero of=/tmp/file bs=1M count=1024
  1024+0 records in
  1024+0 records out
  1073741824 bytes (1.1 GB) copied, 24,9147 s, 43,1 MB/s
How many writes were done to swap?
  Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
  sda3             12,29        86,29       479,66     162996     906020
Hm, 750MB more... I have actually expected it to be about 300-400 MB, but
well, I must have missed something like paging cluster...

Anyway, it's still less than 1GB, so it looks like we saved 250MB of writes,
right? Wrong! Because now we'll READ it back, that's what real app would do.
  # time cat /tmp/file > /dev/null
  real    1m58.916s
  user    0m0.139s
  sys     0m17.287s
So what do we have with r/w stats now:
  Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
  sda3             60,86       567,86       885,15    1243676    1938604
WOW! Reading that tmpfs-file we've done 1GB of reads AND 1GB WRITES.
Instead of 1GB writes for real filesystem, we'd got 1.7GB for tmpfs+swap.

Conclusion: using tmpfs+swap for files that increase amount of free RAM
generate (at least 70%?) MORE WRITES than regular filesystem. And the
more reads you do the more writes it generates. (Imho, that deserves a
place in summary!)

Does anybody still think that tmpfs+swap is good for SSD? ;)

What part of my summary's wrong? The QA part? Those were just theories.
Theories can be wrong, that's why I always ask for tests and examples,
they can't be wrong. Theories are there just to explain results of the
tests. Any theory is useful only when applied to a real life. When the
theory does not match real life it replaced with another theory. That's
how the entire physics work. :) Which of my theories is wrong, BTW?

-- 
  Serge


Reply to: