On 04/03/2012 11:35 AM, Chris Adams wrote:
I have been doing this also but limiting how much space can be used in /etc/fstabOnce upon a time, Brian Wheeler <bdwheele@xxxxxxxxxxx> said:* The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). I've been running with /tmp on tmpfs for several years, including on a number of servers, and I've never had any unusual problem related to it. I typically provision a little more swap on such systems, so that there's some room for spill-over. Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-"auto", /etc/fstab, and now a service for /tmp). Really? Two wasn't enough? with the size= option. To do away with being able to control this seems dumb. --
Stephen Clark NetWolves Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@xxxxxxxxxxxxx http://www.netwolves.com |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
