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:
APPEND CFLAGS -pipe
APPEND CXXFLAGS -pipe
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
--
Serge
Reply to: