/tmp directory too small???
 

Hi,
I was trying to download a big file yesterday (something like 100mb+) using Mozilla. When it was downloading, it is complaining that I don't have enough space in the /tmp directory. I found out that it belongs to a small partition on my hard disk. (FYI it belongs to the same partition as my / )
So I am just wondering if I can should increase the partition size?
Is there any security reason why I shouldn't resize that partition?

How do you guys handle large download files??
Can I specify a temporary directory for mozilla to store the temporary files other than /tmp??

Thanks in advance.:study:

By the way, this forum rocks!!!

nothing wrong with resizing partition

checkout partition magic if u have windows dual boot.

temporarily u can use wget
wget url/to/file in somewhere u have enough free space

If you do not want repartitioning, it can be done more simply:
1. Remove the old /tmp directory,
2. create a tmp directory on a large disk,
3. link the latter to /tmp (ln -s /new/path/to/tmp /tmp).

We did it on a FreeBSD (production) server a week before, and it works well ever since. I think it can be done on Linux, too.
(Although I know it may be better to resize the /tmp partition).

Re: /tmp directory too small???
 

Not uncommon.
If you have unused space on the disk you should be able to.
Not thet I've heard of. Of course, the very paranoid can dream up all sorts of security problems. $DIETY only knows what the bad guys could do with a lot of temp space. They might download MP3s or something. :-)

One thing you could do is to do a little scavenging (it's fun!). It's amazing how may 1GB-3GB disks are being shipped to landfills because no one wants a disk that size (I had a technician at work apologizing because the system she was giving me to load Linux `only' had a 20GB disk in it). If you haven't used up all your IDE connections and know of some business that's upgrading old systems you could find a disk that you could split up for some extra swap space (make it the same size and stripe it with your existing swap partition; best if this disk on on the other IDE channel than the existing swap partition is currently living if you decide to do this) and use the rest for /tmp. Just remember to clean out the contents of the /tmp directory in your root partition before you alter /etc/fstab to mount the new filesystem on /tmp. Otherwise that disk space is inaccessible. It's probably best to do this by booting to single user mode so no users have open files in the existing /tmp.

Good luck,
Rick

Although there are many temporary remedies to this, there are 3 "best practices" related comments, I would make:
-- /tmp should reside on its own filesystem. So I would encourage you to create a dedicated block dev for /tmp if at all possible.
-- /tmp should **always** reside on the OS (/) drive.
-- Although many developers consistently break this rule, /tmp should be primarily a system temp filesystem. Conversely, /usr/tmp ( linked to /var/tmp) is traditionally userspace ("user" being the traditional UNIX definition). Hope this helps.

Yeah, I would say you'd be best off changing the directory Mozilla saves its files to. /tmp is usually made no bigger than 500MB or so. It's not really meant for users to store big files in.

Alex

theklink wrote:
``-- /tmp should **always** reside on the OS (/) drive.''

Always? I disagree. On many systems, /tmp resides on a different disk than the OS to avoid an I/O bottleneck. Back when I was doing admin work on heavily used development system, I got in the habit of putting /tmp on a different disk so as not to have the heavy use of /tmp contending with use of executables in /bin, /sbin, etc. The systems I deal with at work use a similar set up as we have thousands of batch jobs that use /tmp for scratch files, etc. during execution.

I would also disagree with the statement about having users use /usr/tmp as well. That directory, like you mentioned, is quite often a symbolic link to /var/tmp, which most UNIX/Linux installation programs place by default on [drum roll]... the root filesystem.

llama_mem noted:
``/tmp is usually made no bigger than 500MB or so. It's not really meant for users to store big files in.''

And /tmp is hardly ever subject to quotas as well. And when the users discover this, they tend to use /tmp as long term storage to avoid exceeding the quotas in the their home directory. AIX used to ship configured to run a nightly cron job called `skulker' (IIRC) whose job it was to clobber any files in /tmp that were older than a day or so; users who didn't read the policy found out the hard way. The production systems at work have an 8GB 0+1 RAIDset since /tmp gets hit so heavily. Letting /tmp fill up would ruin many people's day (on occasion, it comes close to violating our 80% rule but only for brief periods). I suppose that some gonzo user could find it limiting, but for most desktops, even 500MB would probably be overkill.

Of course, having said all this, when I set up the Linux system for my parents to access the internet, I'll probably put the whole darned OS on a single disk to keep their costs down.

I appreciate your comments. There is definitely a split in philosophy on this. In my past experience I have noticed IBM even recommending a separate /tmp disk. My trouble is I have been burned on it more than once, so I am probably biased. ;)

That being said, I also have never heard of anyone building a serious production system with var on the root fs.
Maybe it's just me...but that practice would make me pretty nervous!
cheers

Interesting. What UNIXes did this?
So I take you chose the ``Custom'' Red Hat install. I recall that the others kept /var in the root filesystem (ugh). Even some commercial UNIX install programs will put /var in the root fs. Tru64, for example; but they at least ask you if you want to move it to its own fs.

Later,
Rick

I do believe mozilla will take advantage of the environmental variable $TMP. You can set this in one of your startup files. Many programs will take advantage of this in user space. It is a good way to allow users to set up their own temporary spaces on multi-user systems without being dependent on the system /tmp or /var/tmp space. Some programs use $TMPDIR instead (or other specific variables).