# Tip/Trick: using tmpfs for /tmp

## adsmith

A nifty little filesystem setting I just ran across is setting /tmp to a tmpfs filesystem.

Basically, tmpfs is a type of filesystem which uses RAM (and swap)  as its device, but it is dynamically allocated, unlike a ramdisk.  Therefore, it only takes as much RAM as it needs.  /dev/shm already uses this.

Assuming you have enough memory, this makes /tmp faster, and I guess it sort of stresses the "temporary" in /tmp, as it will certainly be cleared on reboot.

The downside is that you might run out of memory (oops!).  However, you can set a maximum size for the tmpfs device to allocate.

In my case, however, I have 768MB of RAM, 2GB of swap, and only 1 GB of spare space on my root partition.  In normal use, I never exceed about 5% of swap, so by setting my tmpfs limit at about 1GB, it is extremely unlikely I'll run out of virtual memory, and it is no more likely that I'll run out of space in /tmp than it would be in the normal configuration.

For all the commands and details, here is a great explanation, which I can't top, so I won't bother:

http://www-106.ibm.com/developerworks/library/l-fs3.html

----------

## truekaiser

maybe the person who worte the power management guide for laptops in user doc's needs to read this...

----------

## WladyX

Any problems with it so far?

----------

## adsmith

I've only been running it for a day, but no problems yet.

I've created a file in /tmp over 1GB to make sure the size limit works, and it does.  

Are there any particular tests I should try?  What can you think of that depends heavily on /tmp?

----------

## WladyX

I heard but i'm not sure that mandrake uses tmpfs.

----------

## jwj

I have exactly the same setup as adsmith running without no problems for about a year now. In /etc/fstab I use

```

tmpfs   /tmp   tmpfs   defaults,nosuid,size=1024M,mode=1777   0 0

```

to mount it.

----------

## WladyX

How much ram/swap do you have?

----------

## jwj

As adsmith I have 768MB RAM and 2GB of swap.

----------

## WladyX

I have 1 GB ram and 1 GB swap, i don't think there will be any problems, i'll try the tmpfs soon!

----------

## Gherald

interesting would be to figure out which parts of /var would do well in a tmpfs

----------

## adsmith

Yes, I was thinking about that for the temporary files arising from emerging stuff.

However, considering that emerging some things from source (*ahem* openoffice *ahem*) takes several GB, very few people could do this effectively.

The more one feels comfortable putting in tmpfs, though, is more evidence that he spent too much money on RAM.   :Very Happy: 

----------

## Gherald

well if you make your swap big enough, I can't think of too many negative aspects

it's not like poeple emerge openoffice every day

but I wasn't limiting my thought to just portage... for example pid, lockfiles, etc have no real business being on diskLast edited by Gherald on Sun Dec 19, 2004 5:18 pm; edited 1 time in total

----------

## Taladar

Sourcemage (another source-based Distro I used before Gentoo) uses tmpfs for compilation AFAIK and this reduces Disk I/O and speeds up compilation if you are dealing with lots of small files.

----------

## adsmith

Actually, if I had a laptop, I'd consider tossing /var/log into a tmpfs (and have them save to disk on shutdown or in a cron job or something), since logs are often the only reason for disk access.

----------

## WladyX

What does mode=1777 do?

----------

## jwj

mode=1777 sets sticky bit on directory. Only file owners can delete files in this directory.

----------

## WladyX

Thank you!

----------

## Jinidog

What is when using this with a system with less RAM (e. g. 128 MB RAM).

Of course, there will be many swapping, but it would use all available memory.

Would it still be faster using tmpfs for /tmp and /var/tmp/portage or would that be a slowdown?

----------

## Gherald

Well of course it will be considerably slower.  I am curious just *how* much slower, but all my systems have lots of RAM so it's difficult for me to test what happens when tmpfs starts using virtual memory.

How about you benchmark it for us and post the results?

----------

## adsmith

The problem with that is that I'm not sure how the kernel deals with the priority of tmpfs versus actual memory usage.  Perhaps tmp might run at a speed no slower than it would on disk, but the system itself could come to a grinding halt.

In that case, I'd rather have slow /tmp than a non-responsive system.....

----------

## Jinidog

strange.

On a system with 512 MB of RAM I tested the performance of being /var/tmp/portage a tmpfs.

The results:

without tmpfs:

real    2m41.081s

user    1m48.505s

sys     0m20.697s

with tmpfs:

real    2m58.270s

user    1m50.086s

sys     0m21.272s

Concluding the filesystem in the memory gave worse performance than having a normal Reiser3.6 Filesystem on the harddisk.

CCache was not activated.

I said it, strange.

----------

## Gherald

And for something funny, try: http://www.google.com/search?btnI&q=tmpfs

 *third paragraph wrote:*   

> Tmpfs is recommended for systems that do a lot of compiling and loading of programs
> 
> and have large amounts of memory (> 16 MB) and swap space.

  :Very Happy: 

----------

## Config

For those who have a huge tmpfs on /tmp.... here is my fstab line:

```
none                    /tmp            tmpfs           size=32m        0 0
```

And I've never run into problems so far on my laptop - and I use it heavily since may be 3 month now

Yeah, I like keeping my /tmp small  :Wink: 

----------

## truekaiser

 *Config wrote:*   

> For those who have a huge tmpfs on /tmp.... here is my fstab line:
> 
> ```
> none                    /tmp            tmpfs           size=32m        0 0
> ```
> ...

 

i have to do the following or nothing starts.

```
tmpfs  /dev/shm  tmpfs size=32m  0 0

tmpfs  /tmp  tmpfs defaults,nosuid,size=32m,mode=1777  0 0
```

----------

## Pink

```
tmpfs         /tmp      tmpfs      size=256M         0 0

```

I have mine at 256M (and have for some months) and have compiled OOo, an entirely new install from stage1 and made a cup of tea and have seen no problems, everything is as slick and speedy as ever.

Out of interest I have 512MB for both RAM and swap. I think, as shown above in the brilliant quote about > 16MB RAM, that an awful lot of 'instructions' and advice are regarding much older hardware.

Now this is IMHO, but 768MB ram, with 2GB of swap, and a 1GB tmp partition and being concerned over only having 1GB root: If it was me I would immediately drop the swap to 512 or possibly the same level as the RAM, and drop the tmp to 256 or lower. Thus I would't be too concerned about the 1Gb left on my root (As I would have about 3 1/4 GB). 

/me shrugs. Just thought I'd chip in a tuppence.

----------

## Cazzantonio

with 1gb ram and several gigabytes of hd space to use as swap memory do you think it' safe to use 

```
PORTAGE_TMPDIR=/tmp
```

 ?

Did someone have some problems using tmpfs to compile programs? Consider that a some of ram is used in compiling, if ram gets filled by tmpfs the system could get much slower...

I wonder if there is an option lo limit the amount of phisical ram used without limiting the usage of swap space

----------

## Gherald

but tmpfs on swap is slower than reiserfs on disk

----------

## Jinidog

Okay, I made an emerge -e world using tmpfs for portage.

Nearly every package compiled around 30% faster than they compiled in earlier runs. (confirmed by genlop)

It's not 100% sure, because normaly compiling wasn't the only task of my PC (I surfed besides that) but this time it was.

I have 512 MB RAM and I closed everything during compiling and just had KDE up running.

----------

## drphibes

how much space do you need to emerge a big package like xorg or kde?  i assume one would need to limit tmpfs sizes at mount time in order to guarantee you don't blow out your virtual memory....e.g. 512M max for a 1G physical memory box with, say a 1G swap.  Is 512M enough space to emerge the big packages?   autoclean must be "yes" right or your hosed?

doc

----------

## hds

 *Cazzantonio wrote:*   

> with 1gb ram and several gigabytes of hd space to use as swap memory do you think it' safe to use 
> 
> ```
> PORTAGE_TMPDIR=/tmp
> ```
> ...

 

emerge UT2004   :Laughing: 

btw.. if you are using VMWARE, you cant do that either.

----------

## ahorn

if /tmp and /var/tmp is at tmpfs, it is cleaned out at boot. but gentoo cleans it at the booting process anyway.

how can i disable this to get some more speed at boot?

modify /etc/init.d/bootmisc, yes?

look here in bootmisc:

```
                #

                # Clean up /tmp directory

                #

                if [ -z "${CDBOOT}" ]

                then

                        ebegin "Cleaning /tmp directory"

                        #rm -f /tmp/.X*-lock /tmp/esrv* /tmp/kio* /tmp/jpsock.* /tmp/.fam* &>/dev/null

                        #rm -rf /tmp/.esd* /tmp/orbit-* /tmp/ssh-* /tmp/ksocket-* /tmp/.*-unix &>/dev/null

                        # Make sure our X11 stuff have the correct permissions

                        mkdir -p /tmp/.{ICE,X11}-unix &>/dev/null

                        chown root.root /tmp/.{ICE,X11}-unix &>/dev/null

                        chmod 1777 /tmp/.{ICE,X11}-unix &>/dev/null

                        eend 0

                fi

```

as you see

```
chmod 1777 /tmp/.{ICE,X11}-unix &>/dev/null
```

it is not necessary to mount tmpfs /tmp with mode=1777

----------

## ba747heavy

Hmm, my computer likes to lock up, and it happens with any combination of programs running and not running.  Now I wonder if the fact that my /tmp is a tmpfs has anything to do with it.  Any way to know?  I guess I can mount my /tmp as a normal partition and see what happens.

----------

## beandog

 *Jinidog wrote:*   

> strange.
> 
> On a system with 512 MB of RAM I tested the performance of being /var/tmp/portage a tmpfs.
> 
> The results:
> ...

 

I got the same result.  Oh well.

Still, its cool to use as a replacement for /tmp at least.

Steve

----------

## MighMoS

I put /var/run in a tmpfs file system, so that should I lose power (we had power work being done for a while) or the machine freeze b/c of buggy NVidia drivers, programs wont get confused when they see their old PID files.

----------

## Master One

After reading this very interesting thread, I just wondered, how you guys would use tmpfs if you had a new IBM ThinkPad T42p with 2 GB RAM and a 4 GB swap partition. I'd like to setup my upcoming machine in the most efficient way. BTW Any info, if tmpfs operates well with hibernation of swsuspend2?

----------

## Jinidog

The only way is to benchmark, what is faster for you.

Concluding, I see no sence in mounting a temporary filesystem for the portage-working directory.

If there is enough free RAM, everything what compiling needs is cached in the RAM. It's the same like a filesystem in the RAM.

So, if there is not enough RAM, the cached files are removed from memory.

If it is a temporary filesystem and the memory is full, it has to be swapped, what needs time.

----------

## hds

 *Master One wrote:*   

> 4 GB swap partition

 

whatever came to your mind to setup a 4GB swap? false dope?

----------

## Master One

 *hds wrote:*   

> whatever came to your mind to setup a 4GB swap? false dope?

 

You are right, that would indeed be a little overkill, was sticking with the general rule "twice the RAM"...

As I want to use hibernation on that machine, swap should be at least 2048 MB (or larger? didn't find the time for much reading on this subject with swsusp2 & hibernation).

----------

## Erlend

I've been curious about this for a while.

I notice that I have a gig or so in /tmp - it never seems to get automatically deleted.  I'm not sure if I can delete all of it though.  

I would guess that if people are having slower compile in tmpfs it's because they don't have enough available ram.  Listen to the drive and see if it is using the swap partition?

I was wondering about putting and ext2 filesystem on /tmp /var/tmp and /boot, since this has very little overhead, nice and fast and it doesn't matter if any of this is corrupted.

Any ideas?

Thanks,

Erlend

----------

## hds

 *Erlend wrote:*   

> 
> 
> notice that I have a gig or so in /tmp - it never seems to get automatically deleted.  I'm not sure if I can delete all of it though.  
> 
> 

 

init 1

delete contents of /tmp

init 3 (or whatever your usual runlevel is) - voila

btw.. using ext2 for /boot and / over here, and ext3 for /data (just because i need largefile support [>4GB], otherwise i would use ext2 there as well).

ext2 is still the fastest, while takeing least CPU, IMHO.

and, if you ever f*cked up a reiserfs - sheesh, you will never use reiser again.

if you get hardware errors on your hdd (and this will hapen sooner or later to anyone of us), bet you run ext2 or ext3, because you will no be able to restore anything from your reiser.

beware of reiser, if your S.M.A.R.T will get full!! and until you realize hat, it is too late aleady ;(

----------

## Erlend

 *Quote:*   

> init 1
> 
> delete contents of /tmp
> 
> init 3 (or whatever your usual runlevel is) - voila 

 

Thanks for that.

 *Quote:*   

> you will no be able to restore anything from your reiser. 

 

Is that just because it is too complicated, and no recovery tools exist?

 *Quote:*   

> beware of reiser, if your S.M.A.R.T will get full!! and until you realize hat, it is too late aleady ;(

 

Not sure what you mean I'm afraid?

Erlend

----------

## hds

 *Erlend wrote:*   

> 
> 
>  *hds wrote:*   you will no be able to restore anything from your reiser.  
> 
> Is that just because it is too complicated, and no recovery tools exist?

 

no, recovery tools do exist, but infact of a hardware defect of the HDD, you are simply lost. the recovery tools will fail, at least they did here (reiser3, that was).

they will try to move data, or write a new superblock (depends on the options you give), and fail, because the next block they try will get unwritable as well. this gets into a ratrace, marking blocks as bad all and all over ;(

 *hds wrote:*   

> beware of reiser, if your S.M.A.R.T will get full!! and until you realize hat, it is too late aleady ;(

 

 *Erlend wrote:*   

> 
> 
> Not sure what you mean I'm afraid?
> 
> 

 

i am talking about the harddrives internal "bad block table". if that gets full, an IDE drive will get more and more corrupted with bad blocks at any write acess you do.

in this case, one prefers to save as much data as possible, but reiser will also deny readaccess in this case, because its journal is corrupted!

if you come from DOS, you might be familiar with "lost+found" directory, thats what "checkdisk" did in the very old days.

btw: this is not against reiser in general, i guess this will happen with any journaling filesys infact of hardware defects.

and btw: yes, i do backups, but you are always caught if you did something you wouldnt like to loose. shit happens  :Evil or Very Mad: 

----------

## Erlend

Thanks.  I didn't know any of that.

I guess one advantage of having /tmp /var/tmp in RAM is that it will increase the lifetime of your hard disk - writing/reading small files like crazy can't be particularly good for it.  On that note, is "emerge -e world" "bad" for your CPU?  I'm just wondering if making your computer compile for 30 odd hours is going to affect it's performance/life?

Also, could one not use device-mapper:

echo "0 X linear /dev/ram0 0 /dev/hda4 0" | dmsetup create tmpHybrid

...

mount /dev/mapper/tmpHybrid

So that the first 50MB of /tmp is RAM, and the rest ext2 space?

Erlend

----------

## Master One

 *MighMoS wrote:*   

> I put /var/run in a tmpfs file system, so that should I lose power (we had power work being done for a while) or the machine freeze b/c of buggy NVidia drivers, programs wont get confused when they see their old PID files.

 

This makes no sense at all, because /var/run get's cleaned on every boot anyway, see /etc/init.d/bootmisc:

```
             ebegin "Cleaning /var/lock, /var/run"

                rm -rf /var/run/console.lock /var/run/console/*

                if [[ -z ${CDBOOT} ]] ; then

                        #

                        # Clean up any stale locks.

                        #

                        find /var/lock -type f -print0 | xargs -0 rm -f --

                        #

                        # Clean up /var/run and create /var/run/utmp so that we can login.

                        #

                        for x in $(find /var/run/ ! -type d ! -name utmp ! -name innd.pid ! -n$

                                local daemon=${x##*/}

                                daemon=${daemon%*.pid}

                                # Do not remove pidfiles of already running daemons

                                if [[ -z $(ps --no-heading -C "${daemon}") ]] ; then

                                        if [[ -f ${x} || -L ${x} ]] ; then

                                                rm -f "${x}"

                                        fi

                                fi

                        done

                fi
```

----------

## markandrew

I had /tmp and /var/tmp as tmpfs for a while but went back to normal fs (reiser) after a while as i saw no noticeable speed increase in general usage or during compiling, and emerging large packages, like xorg or openoffice, would fill out the /var/tmp dir and i'd have to start over. dedicating more memory, i decided, wasn't worth it (got 1G ram).

I also had, for a while, my /var/logs dir as tmpfs, with it being read from disk on boot and written back on shutdown. however after a couple of crashes (non related) i realized that if the machine didn't shutdown properly, i lost all my logs for that session... and thus couldn't figure out why the crashes were happening.

in the end i decided it was a nice idea, but didn't give any real benefits.

----------

## Erlend

I've always wondered it having /etc/init.d in ram at boot would speed things up.  I imagine it wouldn't make much difference though?

Just a though, /var is temporary in that it is meant for files which are non-essential, and which don't change very often: surely then that could be tmpfs or some low-overhead filesystem (ext2).

Erlend

----------

## kallamej

 *Erlend wrote:*   

> Just a though, /var is temporary in that it is meant for files which are non-essential, and which don't change very often: surely then that could be tmpfs or some low-overhead filesystem (ext2).

 Do not use tmpfs for /var, portage and other programs depend on it surviving a reboot.

----------

## lost+found

This is how I made a virtual Test/Guest Account in tmpfs /tmp.

```
# useradd test -m -G users,audio,tty -s /bin/bash -d /tmp/test

# passwd test
```

/etc/conf.d/local.start:

```
cp -R /etc/skel /tmp

rename skel test /tmp/skel

chmod 0700 /tmp/test

chown -R test:users /tmp/test
```

Restart...

----------

## mr.ed

K, here r my two cents...

 *Quote:*   

> [15:29][root:-> /]@: df
> 
> /dev/sda3              45G  5.8G   39G  14% /
> 
> udev                 1005M  600K 1004M   1% /dev
> ...

 

 *Quote:*   

> 0 lrwxrwxrwx  1 root root 12 Apr 12 15:25 /tmp -> /dev/shm/tmp
> 
> 0 lrwxrwxrwx  1 root root 12 Apr 12 15:25 /var/tmp -> /dev/shm/tmp

 

This is my fstab-line for /dev/shm (nothing else!)

 *Quote:*   

> tmpfs			/dev/shm		tmpfs		defaults,size=1G					0 0

 

As u can see my tmp-dir is mounted at /dev/shm (which is the standard tmpfs). I noticed this thread before and thought if it would be possible to redirect all of your tmp-dirs to /dev/shm and thus move all of your workfiles to tmpfs... After a bit of searching round i came to the conclusion it can be done and it's a real speedgain to. At first i tried the fstab solution, but it gave 2 much trouble (mount bind and stuff). But then i realised a symlink would do exact the same thing!!!

Basically i just deleted all of the tmp-dirs first and then created the dir /dev/shm/tmp. Then I chmod 1777 /dev/shm/tmp (NOT /dev/shm) and symlinked the tmp-dirs to this folder. 

The only downside is off course u gotta have enough ram to compile larger progs like xorg, kde (for OOo or anything else larger then my tmpfs i remount /var/tmp/portage to a partition). But then u would still have the problem of your ram filling up rather quickly and not getting cleaned... My solution was emerging tmpwatch and modifying the cronscript in such a way that it cleans out my /var/tmp/portage every hour of files that haven't been accessed for one hour and cleans out /tmp every 8 hours. I added the script to cron to be run every half hour, so the cache never outgrows my tmp!!!

The second problem was that the /dev/shm/tmp get's deleted off course at every reboot, so i added this to /etc/init.d/localmount:

 *Quote:*   

> start() {
> 
> 	# Make tmp directories for mounting /etc/fstab.
> 
> 	mount /dev/shm
> ...

 

Any1 paying attention will see that this combination creates a tmp-dir IN tmpfs, not a dir mounted on tmpfs (cause it allready exists with /dev/shm, see your own df -h)

If some1 has questions bout it, i'ld be willing to set up some sort of guide to how to do it...

P.s.: I got 2 gigs of ddr2 ram and i can leave my comp on for days in a row if i'ld like, it runs the same as if temp was normally mounted at a filesystem, but faster  :Wink: ... This setup i've been using for 3 weeks now and never got into trouble with tmp filling up!! (Never grew to more then 75%)

----------

## lost+found

 *mr.ed wrote:*   

> ...but it gave 2 much trouble (mount bind and stuff)...

 

The mount --bind thing is easy...   :Smile: 

This makes /dev/shm and /tmp share one tmpfs.

/etc/conf.d/local.start:

```
cp -Rp /tmp /dev/shm

mount --bind /dev/shm/tmp /tmp
```

 :Exclamation:  cp instead of mkdir, this avoids X11 crash.

/etc/fstab:

```
none  /dev/shm  tmpfs  nodev,nosuid,noexec,noatime,size=256M  0 0
```

Restart...

----------

## mr.ed

 *Quote:*   

> This makes /dev/shm and /tmp share one tmpfs. 
> 
> /etc/conf.d/local.start: 
> 
> Code:
> ...

 

This is a bit weird... Mine implements /tmp BEFORE /tmp and /var/tmp get used (at mountpoint), but yours AFTER? No wonder u had X crashes m8... Look at the dirs in tmp, lol, u should have figured that one out yourself!  :Shocked:  If u create and mount the tmpfs before the rest and at the same time create the tmp-dir, al progs after allready can use the tmpfs... :Idea: 

As for the symlinks: they r easier cause with this u can put virtually EVERYTHING in tmpfs with a simple symlink... Instead of having everything to mount, which takes longer at startup... :Rolling Eyes: 

Third benefit: this way i know for sure my whole tmp is gone on reboot, cause if u don't do the mkdir /dev/shm/tmp, it will complain bout not finding mountpoint tmp! :Wink: 

Finally: mount --bind /dev/shm/tmp /tmp? Why put it in local? Wouldn't it be easier to add this line to fstab: /tmp   /dev/shm/tmp     tmpfs     bind      0 0? Or better yet:  tmpfs     /dev/shm/tmp    tmpfs     defaults,mode=1777,size=512M???

----------

## lost+found

 *mr.ed wrote:*   

> This is a bit weird... Mine implements /tmp BEFORE /tmp and /var/tmp get used (at mountpoint), but yours AFTER? No wonder u had X crashes m8... Look at the dirs in tmp, lol, u should have figured that one out yourself!  If u create and mount the tmpfs before the rest and at the same time create the tmp-dir, al progs after allready can use the tmpfs...

 It works fine.  :Very Happy:  I didn't want to mess up the init scripts, and local.start is for your own commands. The only things copied over are 2 empty dirs .X11-unix and .ICE-unix in /tmp, made by bootmisc. No big deal.

 *mr.ed wrote:*   

> Finally: mount --bind /dev/shm/tmp /tmp? Why put it in local? Wouldn't it be easier to add this line to fstab: /tmp   /dev/shm/tmp     tmpfs     bind      0 0? Or better yet:  tmpfs     /dev/shm/tmp    tmpfs     defaults,mode=1777,size=512M???

 /tmp must be copied to /dev/shm first, so fstab wil be to early to bind mount. But changing localmount would be more right.

/etc/init.d/localmount:

```
...

start() {

# Mount local filesystems in /etc/fstab.

ebegin "Mounting local filesystems"

mount -at nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null

### bind mount

mkdir -m 1777 /dev/shm/tmp

mount --bind /dev/shm/tmp /tmp >/dev/null

###

eend $? "Some local filesystem failed to mount"

...
```

Last edited by lost+found on Mon Apr 25, 2005 6:15 am; edited 2 times in total

----------

## DrWoland

Can tmpfs be set to noexec?

Edit: Sure can!!

----------

## lost+found

 *DrWoland wrote:*   

> Can tmpfs be set to noexec?
> 
> Edit: Sure can!!

 http://www.gentoo.org/doc/en/gentoo-security.xml#doc_chap5

Any problem script detected so far?

----------

## mr.ed

lost+found wrote:

 *Quote:*   

> DrWoland wrote:
> 
>   Can tmpfs be set to noexec? 
> 
> Edit: Sure can!!
> ...

 

There should be no problems, unless u put the portage tmp dir in /tmp: emerge needs be able to execute scripts!! (u will get an error similar to this: /usr/portage/eclass/kde.eclass: ./configure: /bin/sh: bad interpreter)

lost+found wrote:

 *Quote:*   

> /tmp must be copied to /dev/shm first, so fstab wil be to early to bind mount. But changing localmount would be more right. 

 

Uh and now u r hacking scripts to make your 'trick' work? lol man, u said before u didn't like to do that ( I didn't want to mess up the init scripts, and local.start is for your own commands) ... Tmp doesn't need to be copied first, cause if u do it right it all gets deleted on reboot and thus the only thing u 'need' to do is make a new tmp-folder on startup!!! It's a bit more logical then your approach: u delete the whole tmp at shutdown and create a new one at startup (instead of copying the existing tmp over, evil script kiddies would love that one)... An excerpt of how i do it:

 *Quote:*   

> 	# Make tmp directories for mounting /etc/fstab.
> 
> 	ebegin "Creating and mounting tmpfs filesystems (tmpfs)"
> 
> 	mount /dev/shm
> ...

 

And yeah, mkdir -m 1777 is the same, but if something goes wrong or doesn't work, it's easier this way to check where it went wrong...

I really don't get why u think lost+found, that i don't know anything m8... U trying to convince me to do otherwise (afk your approach), try to flame my posts, but in the end your own posts get flamed with better arguments to which u have no reply... And u contradict yourself!!! That's no problem at all btw, allways like a good discussion bout something, but be carefull when u quote something....

----------

## adsmith

Actually, I don't see why either of you are bothering to make /tmp a subdir of /dev/shm.  There is no harm in having multiple tmpfs's.

----------

## NotQuiteSane

hey peoples,

I have both /tmp and /var/tmp on tmpfs (also encrypted swap)

I'm playing around trying to create an encrypted /tmp.  I try:

```
cryptsetup -c serpent -d /dev/urandom create temp /dev/shm/

& 

cryptsetup -c serpent -d /dev/urandom create temp none

& 

cryptsetup -c serpent -d /dev/urandom create temp tmpfs
```

All 3 return the same error message:

```
Command failed: Block device required
```

so, question one, what is the proper block device for tmpfs, and two, considering /tmp is mounted in "memory" vs "disk" and I already have encrypted swap, do I need to encrypt it?  perhaps a hourly cron job to shred/delete anything older than X minutes would work just as well?   

NQS

----------

## Garr

and recently at work - I found out why  :Smile: 

if anyone has looked after mysql on a server before, they may know about some of the little "issues" mysql has, such as filling up the partition (usually /var), and thus crashing the whole damn server.

Most MySQL queries are collated in memory.  If there is an output over a certain size (configured in the my.cnf) it will dump the answer out to the disk, /tmp by default.

If your webdevs make stupid mistakes (I have found the orderby command can often be the culprit), and the server spirals out into oblivion - if you use tmpfs - it will simply crash the thread, and give a nice error (something like error blah /tmp/XyZcTpB).  But the server keeps on keeping on.

I am not sure if only the one thead crashes, is because we use a J2EE server to talk to the mysqldb, but eh - whatever - I love it  :Smile:   Much better than a 4am call from the data center coz somebody left in a stupid line of code on a query that only gets used once a week - at 4 am  :Wink: 

----------

## Drysh

I'm using tmpfs for a month now, and it seems to be working.. 

My fstab is:

```
/dev/sda1      /boot            ext2          noatime                                 1 2

/dev/sda2      /                reiserfs      noatime                                 0 0

/dev/sda3      /files           xfs           osyncisdsync                            1 1

/dev/sda4      none             swap          sw                                      0 0

proc           /proc            proc          defaults                                0 0

tmpfs          /dev/shm         tmpfs         defaults,nosuid,size=3072M,mode=1777    0 0

/dev/shm       /tmp             none          rw,bind                                 0 0

/dev/shm       /var/tmp         none          rw,bind                                 0 0
```

And my swap is:

```
Filename        Size        Used       Priority

/dev/sda4      4140856      226232     -1
```

I have 1GB RAM, so I'm using this huge swap to avoid:

- errors when emerging large packages;

- the system not responding because there is no memory.

I'm using a single tmpfs to reduce the chance of having one filled up and another empty (without reserving cache for each one); and to make it easier to manage that (I don't have to think about how much each directory uses). I never saw any problem with /dev/shm, /tmp and /var/tmp being the same directory. Portage is using /dev/shm as temporary file.

I tested compilling oppenoffice, while running gnome and having gimp with large image files opened.. Everything seems fine. What I noticed is that the system is much faster when I'm doing the same thing for some time.. I mean, the applications seems to speed up after 1 or 2 minutes running. I still need to perform more methodical mesures of performance (time everything), because I was more concerned with making it work than making it fast.

Does anyone see anything wrong with what I'm using? Is it too much swap? (Apparently I'm using less then 1GB most of the time, but during the test I saw more than 2 GB of swap.) Is there any problem binding the way I did (everything in the same directory)?

And while we are at it, about that xfs.. I heard osyncisdsync is now default, is it true? BTW, I'm using xfs for /files, a directory I created to store all my common use files, like: mp3, images (photos), videos, docs that I read a lot but do not edit, etc. Since xfs is very fast reading and not so fast writting, it worked like a charm. But I'm still taking suggestions for this one.

----------

## Drysh

NotQuiteSane:

Take a look at this: *The 'Advanced filesystem implementor's guide', on IBM forums wrote:*   

> Not a block device
> 
> Here's another interesting property of the tmpfs filesystem. Unlike most "normal" filesystems, like ext3, ext2, XFS, JFS, ReiserFS and friends, tmpfs does not exist on top of an underlying block device. Because tmpfs sits on top of VM directly, you can create a tmpfs filesystem with a simple mount command:
> 
> ```
> ...

 

I think there isn't a block device after all. Isn't there an option for cryptography with tmpfs in the kernel config? I remember something about it, but I'm not sure.

I hope it helps. Please, post the results if you find how to use them together.

----------

## Drysh

I'm having a small problem with /tmp... Some packages create special directories under /tmp and they expect them to be there after reboot. One example is gimp. It creates /tmp/gimp-2.2 to use as a swap file, and it complains that it doesn't exist (since it disapears after a reboot). The way I'm using to fix this is a rc script to create these directories.

Some questions:

1. Is it a problem to set the swap directory of gimp to /tmp? I'm afraid it might confuse some file with other applications.

2. Does anyone knows how tmpfs manages memory? Will it be problematic to create a lot of tmpfs (one for each directory)? Or is it better to make like I did (see post above), binding them in a single tmpfs?

3. Any ideas how to handle multiple directories with tmpfs: with data that may be lost, but with a structure (sub-dirs) that needs to survive a reboot?

----------

## adsmith

 *Drysh wrote:*   

> I'm having a small problem with /tmp... Some packages create special directories under /tmp and they expect them to be there after reboot. 
> 
> 

 

this should not happen.  no program should assume /tmp is permanent.  If gimp does this, it should be considered a bug.  If directoried are supposed to be persistent, they should reside in your home directory or in some permanent system directory.

 *Quote:*   

> 
> 
> 2. Does anyone knows how tmpfs manages memory? Will it be problematic to create a lot of tmpfs (one for each directory)? Or is it better to make like I did (see post above), binding them in a single tmpfs?
> 
> 

 

it doesn't matter.  If nothing is in a tmpfs, it takes up no space.  there is no problem having multiple tmpfs's.

 *Quote:*   

> 
> 
> 3. Any ideas how to handle multiple directories with tmpfs: with data that may be lost, but with a structure (sub-dirs) that needs to survive a reboot?

 

of you really want to do this, add

   mv /my/tmpfs /somewhere/permanent/

to /etc/conf.d/local.stop

and  add

   mv /somewhere/permanent/tmpfs /my

to /etc/conf.d/local.start

----------

## Drysh

Thanks!

I'm using...

mkdir /tmp/gimp

...in local.start and it works now. Gimp doesn't create the directory.

----------

