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

Re: Moving /tmp to tmpfs makes it useful

2012/6/5 Goswin von Brederlow wrote:

> You keep claiming tmpfs compromises system stability. Can you show a
> kernel oops of a crash caused by tmpfs?

No crashes, system just becomes slow and hard/impossible to use. See the
Stefan Lippers-Hollmann email about tmpfs vs disk writes. System that
does not respond to mouse clicks I called "less stable". I don't mind if
you suggest a better name for it.

> A short-livd file goes to cache, as dirty pages. dirty pages are then
> written to disk in the background. Are you claiming that filesystem do
> un-dirty pages when a file is deleted before it was actually written to
> disk?

Yes, I tested that. It's easy to test, run:
  dd if=/dev/zero of=testfile bs=1M count=20; rm -f testfile
then check /proc/diskstats or `iostat -k` for actually written bytes.

> As Mike says any fsync on the same filesystem generaly will force write
> the files in /tmp too.

It does not (Mike, are you sure?). I wrote a small test to check fsync
speed. Certainly fsync becomes slower on a heavily loaded disk. But it
becomes about same slower when I READ from disk instead of writing to it.
Fsync also does not cause the data to be flushed (there was about 50MB
of data in cache, but fsync usually took <0.1s, my disk is not that fast).
Can you actually reproduce that on your system?

>> 5. if you build a package, you can add it to global build options
> Not the default and you were talking about inexperienced users.

If the user is experienced enough to build a package, he can write:
to the /etc/dpkg/buildflags.conf as well. :)
(maybe it should be there by default, btw?)

> I think more than "nobody" has an SSD disk nowadays and they will only
> become more popular. At best ignoring SSDs is short sighted.

Ehm... I don't understand you. There're a lot of blind people there, and
ignoring them is also not the best idea. But how is that related to /tmp
on tmpfs? It does almost no help for SSD disks, because most writes are
not done to /tmp.

I don't know any people, who care about disk writes AND build packages
on SSD disks. But I think you're right, that they will become more and
more popular. At the same time they become more reliable, so if we're
talking about future — we don't have to worry about SSD at all, because
even modern SSD disks are supposed to live for 50+ years. :) [1]

> Unfortunately that limit seems to simply not work AT ALL. Writing to a
> slow filesystem like NFS or a USB stick just keeps writing and writing
> and writing till there is no more ram. With the obvious result of stuff
> blocking.

I don't have NFS to check, but I often write to USB disks, that are much
slower than my HDD, and get no swapping/blocking.

> Also shouldn't/couldn't tmpfs fall under the same ratio (or equivalent
> setting). No more than dirty_ratio pages should be dirty in tmpfs and
> then it could start swapping them out even without memory pressure?

IMHO, tmpfs is a filesystem in RAM, not a cache for "swap filesystem", so
dirty pages should be "flushed" to RAM, not to swap.

>> It won't, I tried. As long as there's enough RAM they don't get swapped.
> Well, worked here.

Maybe you have some unusual sysctl settings, e.g. vm.swappiness?

>> Which of them becomes faster with /tmp on tmpfs? Can you suggest a use
>> case, that I can test with /tmp on disk and on tmpfs myself and see them
>> becoming faster?
> All of them. In mc use the feature to look into tar/rpm/deb files.
> And try running apt-get upgrade in parallel for extra fsync()s.

I can't reproduce the fsync() problem, see above. Can you?
(also, mc does not unpack rpm/deb to /tmp when looking into it :))

[1] http://www.storagesearch.com/ssdmyths-endurance.html

Reply to: