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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoveneo8cqm9p3cksqi6xpg05cczpgt-qzmb56+kmh761xg...@mail.gmail.com
