Re: Moving /tmp to tmpfs makes it useful
- To: Goswin von Brederlow <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: Moving /tmp to tmpfs makes it useful
- From: Serge <email@example.com>
- Date: Tue, 5 Jun 2012 13:45:38 +0300
- Message-id: <CAOVenEo8CqM9P3cksqi6xpg05cCzpgt-QzmB56+KMh761XgPBQ@mail.gmail.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <CAOVenEo+CT6Ou_vHq8HvuCz1NdW0Ogq5UqxMZh-4Qkw4e01CsA@mail.gmail.com> <20120525003051.GA1497@jwilk.net> <email@example.com> <CAOVenEqx1VLBmn4eJdFJ29PUj5ebJp9DHrMea7gprF8+GZd5Fg@mail.gmail.com> <4FBF16A3.firstname.lastname@example.org> <20120525101420.GA6872@khazad-dum.debian.net> <Pine.BSM.4.64L.email@example.com> <CAOVenEp+mr3yNi=4obCG2qtztFjuAJ_SvcUS1Y-7iJ5mNhj9GA@mail.gmail.com> <20120525125607.GC16397@belkar.wrar.name> <CAOVenEqkgq7pUD1xeneRvFxwzRh3qXk_xD9eWeUz7nKjDT2Chg@mail.gmail.com> <Pine.BSM.4.64L.firstname.lastname@example.org> <CAOVenEqwGS5sEgV6vAmyOQ0NX7Ro+14tLN79WYk6u1KF0bCEemail@example.com> <firstname.lastname@example.org> <email@example.com> <CAOVenEpfRZMzZPpsux8fib9G0cE-GnOum-mDkZn2NzkYXFWBvw@mail.gmail.com> <firstname.lastname@example.org>
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
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. :) 
> 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
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 :))