On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta <jspaleta@xxxxxxxxx> wrote: > As a sysadmin...for a multi-seat configuration in a home network > environment...do I really need to anticipate maximum large file tmp > usage in calculating my swap partition size for my multi-user family? > 8 gigs of ram... so to be safe I want to set up a swap of what...100 > gigs to account for a potentially large /tmp of some maximum size? This is an issue you have independent of tmpfs. How big does / need to be? (or if /tmp is on another volume due to the fragmentation mess it creates, how big does that volume need to be). > Does swap backed tmpfs as /tmp currently jeopardize my system's health > by making swap backup for in-memory processes compete with tmp files? > If my users clog up /tmp will that reach a point where the kernel's > oom process killer decided to start killing off running processes > instead of throwing crap out of /tmp? Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem If you set it high enough that you could fill swap and physical ram with tmpfs plus your workload, then yes, I believe you'd then see the OOM killer run. I've never had this happen because I've never set my tmpfs size larger than the available swap I had— so any OOM event always was due to applications using up too much core. > What happens when I have 2 users who are both downloading dvd iso > sized images into /tmp as well as other things going on. Remind me... > where does firefox by default cache in progress downloads for the > "Open in" facility. Isn't it down in tmp? Do I really want things > like firefox downloads paging out ram into swap and causing an overall > system slowdown? Yes, Firefox saves to /tmp by default. Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems. > Without more information about how gracefully /tmp spill over into > swap is handled, I'm inclined to say this really looks problematic as > a default. > And that's not even getting into the more complex issues of virtual > machine configurations which typically run under heavier ram > constraints than disk constraints. It really sounds to me that you're using a "ramdisk" as a mental model for tmpfs. That isn't what tmpfs is. Tmpfs is a filesystem backed by the kernel's buffer cache, and it can use whatever resources it likes to back it up. In practice small short lived things are purely in ram, while larger long lived data ends up on disk— but it does so at the kernel's leisure and in a manner which minimizes writes and latency critical operations. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
