On 01/28/2014 10:05 AM, Peter wrote:
On 27/01/14 00:04, Carlos E. R. wrote:
On 2014-01-26 23:50, Peter wrote:
Does it make any difference in your opinion to have /tmp on a separate partition on an SSD rather than lumping everything in with / ?
Having it all on the same partition spreads writes over the disk, instead of concentrating them on a smaller area. So yes, a single partition for all is better in that respect. IMO.
I can see the logic in that. I've never had a separate /tmp previously so I'll just go with my usual setup.
As I said, its about risk management. On production machines and ones exposed to the 'Net I use a separate /tmp that has noexec,nodev,nosuid In fact that applies to ~/Downloads as well! In fact I think there is a lot that should be mounted that way.
On 27/01/14 02:55, Anton Aylward wrote:>
I don't know how modern that laptop is. Having only 4G seems small to me. But using memory for /tmp *is* an option.
The laptop is of 2008 vintage, which will doubtless seem very old to some folks but this is a recent upgrade from my nine-year-old predecessor, and aside from the slow HDD it is a very noticeable improvement for me that generally surpasses my own particular needs. So 4G RAM is already 4x what I had on my old machine!
I feel for you! I upgraded (?!?) from a 1.25G mid 90s laptop to a 4G workstation. The problem is that the workstation is lower despite being a faster clock, more memory and 64-bit. The reason is the laptop was multi-core and this workstation is single core. memory was never the problem. Even with heavy tabbing in Firefox I'm not using all memory. If /tmp were to be flushed properly I could run it as a tmpfs.
Linux can do some marvellous things. Not only can you do tricks with mounts - rbind - but also with the overlayFS.
Having a separate /tmp you can mount it with noexec,nosuid, nodev options. That too is manages risk.
If I were you and if it were possible, I'd work out a way so that when you are at the docking station the HD is used as /tmp.
It may be as simple as a 'mount'. If the mount fails 'cos you are 'elsewhere' then the /tmp that was the mount point is used.
I toyed with this concept, not knowing how on Earth I would actually go about it, but I fear nasty repercussions. How would the system cope, when undocking it, with a load of temp files it thinks are available in a certain location no longer being there?
You are talking about undocking while live? If not then there are two issues, since so much of the system is designed to cope with a tmpFS /tmp which vanishes on shutdown. If you are undocking while live then that's scary! The first issue is that the system recreates what it needs or uses something else. The the second is that if you re using /tmp for anything that you want to survive a reboot then you are abusing the 'definition' and should be storing it somewhere else. /tmp is for transients.
It's not practical to have to sync everything back onto the SSD at those times, and I'm not convinced that it will capably respawn temp files as necessary.
Like what? The systemd stuff and the Xorg stuff does get re-spawned, or recreated when things are restarted. What else are you talking about?
One of the reasons I'm doing this upgrade now is because I need to do a fresh install after screwing the machine up deleting everything in my /tmp a few weeks ago, following a moment where it had mysteriously filled / to the brim and no process seemed to want to do anything about it. Since I did that, I've had a multitude of problems.
Deleting stuff from /tmp on a live system will create problems. If you need to clean it go into single user mode. The fact that filling /tmp fills / as well is a good reason to partition!
The laptop often refuses to suspend to RAM, or shutdown / restart / logout.
That's a different set of problems. Some updates to KDE, for example, lost that ability. If I run 'shutdown -h now" I don't always get a power-off. Sometimes not even if I use "shutdown -h -P now". Flaky, yes, but life's like that. Oddly restart always works :-) I've never got suspend to work reliably, certainly not twice in one 'power-up'. All this is a different matter and I don't think it has anything to do with whether /tmp is part of /, a separate partition or a tmpFS.
All the previous discussion about how openSUSE doesn't follow the systemd upstream defaults of clearing /tmp on boot, makes me think that until this distro resolves these issues I don't really want to start messing again with temp files by moving or deleting them, or interfering in any other way. From my perspective, the current setup is busted, because I've noticed an accumulation of temp files on a couple of other openSUSE 12.3 systems that can suddenly fill up /, and neither reboots nor the supposed systemd process that took over from sysconfig/cron for cleaning temp seems to have any effect. On my parents' machine, for example, I created a root partition of about 14GB of which about 6GB is filled after system installation, and a separate /home. Since they're in another country and I don't have remote administration set up, when I return I find their root partition is full. All they do is surf the web and check emails. This is just a bad distro default, IMO. It shouldn't ever happen.
I agree that there is something wrong. /tmp shouldn't just fill up like that. I'll mention in passing that I have a second 20G drive with Redhat installed on which I do run the tmpFS for /tmp and it doesn't seem to present any problems.
Question: Are you using a separate partition for /home? What about /usr/local?
I always have /home separate, and /boot too. But that's as far as I go usually. My new SSD isn't huge, only 120GB.
I think that's huge! My old laptop only had an 80G drive and I never filled that. OK, I had backup to an archive server and mail was IMAP to mail that lived on another machine, but still... And as I say, so long as I do that and have /home elsewhere, the 20G drive is more than enough for the system.
I'll be keeping a lot of personal files like music / images on portable USB-attached drives for portability to other (also v. old) machines. So splitting the root partition further isn't great as I'm not the best judge of how much space to allocate and which might then go wasted. From that perspective it's probably better to just have a larger /.
On production machines I use LVM to address the 'how much space' issue. -- Though force can protect in emergency, only justice, fairness, consideration and co-operation can finally lead men to the dawn of eternal peace. -- Dwight D. Eisenhower -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org