On Wed, May 18, 2011 at 12:54 PM, Tom Gundersen <[email protected]> wrote: > On Wed, May 18, 2011 at 7:41 PM, Dave Reisner <[email protected]> wrote: >> Additionally, clearing /tmp in /etc/rc.local is too late. Daemons are >> already started at this point. X might even be running. We can't blindly >> rip out this data. If we really wanted to go this route (and I >> personally don't think we should), we would need to add another hook >> within rc.sysint shortly after root is remounted rw, which would be the >> appropriate time for this to happen. > > Meh, you convinced me. I'll just reinstate the old behavior. We will > not support preserving /tmp. > >> I disagree. Arch doesn't push any default setting of mounting tmpfs on >> /tmp, so I think the majority use case is that the rm call removes >> something. The opt-in behavior (the edge case) is where this becomes >> a NOOP. > > I guess I rather should have suggested making /tmp as tmpfs the > default, because there really is no good reason (at least I have not > been able to find any) for doing anything else (yet people are doing > it...). I guess a case could be made for keeping /tmp on the root > device, but I don't think it is a good idea either.
I think the right conclusion has been reached (don't change anything), but I will add that expecting everyone to have /tmp as a tmpfs is extremely limiting. I also disagree with your unbacked-with-facts conclusion that "99.99%" of people are satisfied with a /tmp on tmpfs; of my 5 machines running Arch only 2 have /tmp on tmpfs. I can think of several situations where this is just plain impractical: * Running on a VPS/VM with limited RAM * Any situation that requires /tmp to be bigger than the size of RAM (or even bigger than half of it) * Any setup where I have a highly performant RAID setup (or maybe SSDs are involved); being on disk will be just fine -Dan
