Is there any advantage of having /tmp on tmpfs using following fstab entry?
I have seen many articles on the net on this but many have been old and apparently now wheezy mounts it as a default (http://www.legendiary.at/2012/03/21/...fs-by-default/) but it is not so on my recently installed Debian-testing system.

If yes, which of above 2 lines should be added to fstab?

There's s few advantages to running tmp in memory, memory is a lot quicker to read and write to, which can speed up some processes that utilise the tmp, for example, if you rip audio or movies this can speed the process considerably. For ssd drives you can reduce the amount of unnessasary writes to the drive, thus increasing the life span of the drive. You can get a build up of temp files that can sit in the tmp directory when it's mounted in the normal location on the drive and take up space that can be used for other things, having it in memory will remove them every time you reboot.

I would prefer this one because it gives you more control and options so you can make it to your liking depending on what you do with this computer

How about adding other tmpfs entries in fstab on Debian, if I want to install on an external usb device:
http://wiki.geteasypeasy.com/How_to:...ur_Flash_Drive
https://wiki.archlinux.org/index.php/Fstab#tmpfs

Debian-testing is using some folders on tmpfs even without any fstab entries:

In my experience mounting /tmp on tmpfs does not give you any advantages, only disadvantages.

In embedded Linux /tmp is usually soft-linked to some directory under /var, but only because /var is usually the only available location that is writable (embedded linux that is!)
If you have an SSD you might also choose for that option. Then again, why get a fast disk if you don't use it...

But why you would want to mount /var/log on a ramdisk is beyond me. Why? The whole reason you have logs is to trace back what happened. After a reboot your tmpfs systems are empty so you can forget about any tracing. And I cannot imagine you would use tmpfs for performance reasons as syslog buffers writes, so your application can continue even if the log hasn't been written to disk.

The reason Debian mounts /var/lock and /var/run on separate disks is that you can always start an application and/or service, even if your /var partition (or '/') fills up completely. Sometimes your applications create so much logging that they will fill up /var/log completely and, as a result, also /var or '/'. If Linux cannot write to /var/lock or /var/run it cannot start any application or service anymore. They are tmpfs system for this reason only.

Anyways....my advice would be to forget about using tmpfs for /tmp but use a regular disk partition instead.

Have to agree with geox here on this one, /var/log is important to troubleshoot if anything goes wrong, that doesn't mean to say that you shouldn't do it. You can experiment with it and see if it works for you, just make sure you backup your /etc/fstab file firest, I have tried that myself for my SSD, in the end I decided to use an old 8gb flash drive I had laying around, it now handles the /var/log directory, when it fails i'll just by another one, cheap enough. I still run my /tmp, /var/tmp in memory, as well as the /run /var/run that ubuntu places in memory by default.

My advise would be to experiment with it and see if it causes you any trouble, or gain any speed out of it, that would be the only way you know if there will be any benefits to doing it. I have had no problems with mine, and I do the usuall stuff, surf the web, emails, rip movies etc...

I disagree. Using tmpfs on /tmp gives me a serious speed increase when compiling things in /tmp. I can compile a kernel with -j10 in /tmp without much I/O-waits, but I can only use -j6 on a fast SSD.

RAM is faster than any SSD. So, why get fast RAM if you don't use it?

I originally started using my /tmp dir with tmpfs just so I wouldn't have temp files always writing to my SSD. With RAM so cheap these days, I've recently started loading my whole rootfs into RAM. Much faster than SSD, and saves on write cycles.

Well, for one because RAM is so much more expensive. And two, Since my RAM is restricted I use it for other things. There are absolutely valid cases for using tmpfs for /tmp but most of the times I find a tmpfs simply too small.

So you need a rootfs of only a few GB? (see previous argument)

As you can see in his sig his main system has 32GB of RAM, so the rootfs can be fairly large. I use tmpfs for /tmp on a machine with 16GB. Of course on a system with 2GB or less this isn't really an option.

That actually a nice idea, might try that myself since i'm running 16gb. That gives me an idea, now that i'm running Lubuntu which supports aufs, for machines with limited ram you could mount rootfs as read-only and create a ramdisk for the write files branch, this would save much space and would make the writes much faster. Of course the only draw back would be you would lose any changes with each reboot, make a nice experiment though.

I have a script that alternates between my SSD and a HDD to sync back the changes. I suppose in the even of a crash, I go back in time a few hours.

Maybe you should look at aufs, you can set it up so it writes to the hdd so you don't have to worry about scripts, you wont lose and data it you have a crash then.

Fotoguy: If you use aufs you state that all changes will be lost on reboot. So that contradicts your statement about not losing data.

Putting your rootfs in a ramdisk is something embedded systems do a lot and i have a lot of experience with this particular setup. Embedded systems do this mainly to reduce flash disk wear. They do NOT use an SSD but rather regular flash, which is not optimized to reduce disk wear. An SSD is.

If an embedded system uses RAM as a rootfs they implement a lot of workarounds to get it to work consistently. This is not easy to do. If you put your rootfs in RAM be aware of these drawbacks. You WILL lose changes. You will gain speed, but due to disk caching in Linux this will be minimal.

A ramdisk is faster and reduces wear on your SSD but considering the very minor performance increase, the fact SSD's are optimized to reduce wear already and the drawbacks mentioned I'd say this setup has advantages for very few setups/uses. Compiling 3-4 linux kernels a day is one of those uses.

Sorry I should have made myself a little clearer with replica9000 post, people may not familiar with unionfs filesystems. Aufs creates branches, which are read-only, and read-write, with live cd/dvd which use unionfs filesystems, the read-write branch is usually on a ramdisk, which will be lost on reboot/restart, but in replica9000 situation using a hdd which is read-write, you could just create a read-write branch that would point to the hdd, so any modification are made dynamically and would not be lost on reboot/restart. Not sure how easy this would be to do, haven't done it myself, but i'm looking into something like this myself for a bit of experimentation.

Ah, much like running from a LiveCD then