[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote:
Personally I thing DVD ISO images (downloaded) belong in your $HOME

Don’t you think this is getting quite ridiculous? Big temporary files belong in your $HOME, but small temporary files in /tmp? Only to switch /tmp from disk to RAM?

somewhere. And locally generated should just pipe the image to the
burner unless you want to upload the image somewhere, in which case

Or you want to keep it safe, until you are sure the burned DVD is working.

Of course, if I want to keep the ISO it will be stored in $HOME, but then it isn’t a *temporary* file anymore. And /tmp *is* for temporary files.

$HOME again. Just imagine a power failure after you painstackingly
uploaded 99.9% of the iso and then you have to start from scratch again
because a reboot cleans /tmp.

TMPTIME exists and can be set according to your needs and your safety concern.

Just out of interest: Do you have /tmp on /? Because if you do already
have a seperate /tmp partition then that obviously stays used.

I always have separate partitions for /, /usr, /var, /tmp, /usr/local and /home (allright, with crappy software like udev and Co. which starts wanting files in /usr needlessy at the early boot stages, I will merge / and /usr in time). It isn’t a problem for me.

But we are talking about defaults. You wish to tell new users that there two TB disk can’t really be used as they wish because Debian has a strange distinction between temporary files belonging in /tmp and temporary files don’t belonging in /tmp?

According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM.

Shade and sweet water!


| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: