df -h (ubuntu 7.x) varrun 252M 88K 252M 1% /var/run varlock 252M 0 252M 0% /var/lock udev 252M 44K 252M 1% /dev devshm 252M 0 252M 0% /dev/shm lrm 252M 34M 218M 14% /lib/modules/2.6.22-15-generic/volatile #/etc/fstab (ubuntu 7.x) # <file system> <mount point> <type> <options> <dump> <pass> # /dev/sda1 (UUID=85699285-aff8-4913-bb74-6cdaf5547de3) # /dev/sda5 (UUID=d18a9139-66f3-4da7-a972-7e8ff4f4c8c3) proc /proc proc defaults 0 0 UUID=85699285-aff8-4913-bb74-6cdaf5547de3 / ext3 defaults,errors=remount-ro 0 1 UUID=d18a9139-66f3-4da7-a972-7e8ff4f4c8c3 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto,exec 0 0 -------------------------------------------------------------------------------- /opt ? aufs - another unionfs http://aufs.sourceforge.net/aufs.html http://en.wikipedia.org/wiki/Aufs -------------------------------------------------------------------------------- devfs | /dev if [ -r /proc/mounts ] ; then if grep -q "/dev devfs" /proc/mounts ; then echo "You do not need to run this script as your system uses de$ exit; fi fi -------------------------------------------------------------------------------- sysfs | /sysfs http://en.wikipedia.org/wiki/Sysfs Sysfs is a virtual file system provided by Linux 2.6. Sysfs exports information about devices and drivers from the kernel device model to userspace, and is also used for configuration. Sysfs is designed to export the information present in the device tree which would then no longer clutter up procfs. It was written by Patrick Mochel. Maneesh Soni later wrote the sysfs backing store patch to reduce memory usage on large systems. For each object added in the driver model tree (drivers, devices including class devices) a directory in sysfs is created. The parent/child relationship is reflected with subdirectories under /sys/devices/ (reflecting the physical layout). The subdirectory /sys/bus/ is populated with symbolic links, reflecting how the devices belong to different busses. /sys/class/ shows devices grouped according to classes, like network, while /sys/block/ contains the block devices. For device drivers and devices, attributes may be created. These are simple files; the rule is that they should only contain a single value and/or allow a single value to be set (unlike some files in procfs, which need to be heavily parsed). These files show up in the subdirectory of the device driver respective to the device. Using attribute groups, a subdirectory filled with attributes may also be created. -------------------------------------------------------------------------------- configfs | /config Configfs is a virtual file system provided by the 2.6 Linux kernel. Configfs appears similar to sysfs but differs in that configfs is for managing kernel objects, and sysfs for viewing. It is typically mounted at /config. -------------------------------------------------------------------------------- tmpfs | /dev/shm http://en.wikipedia.org/wiki/Tmpfs Everything stored in tmpfs is temporary in the sense that no files will be created on the hard drive; however, swap space is used as backing store in case of low memory situations. On reboot, everything in tmpfs will be lost. The memory used by tmpfs grows and shrinks to accommodate the files it contains and can be swapped out to swap space. tmpfs is supported by the Linux kernel from version 2.4 and up.[3] tmpfs (previously known as shmfs) distinguishes itself from the Linux ramdisk device by allocating memory dynamically and by allowing less-used pages to be moved onto swap space. RAMFS, in contrast, does not make use of virtual memory (which can be an advantage or disadvantage). In addition, MFS and some older versions of ramfs did not grow and shrink dynamically and instead used a fixed amount of memory at all times. Usage of tmpfs for example is "mount -t tmpfs -o size=1G,nr_inodes=10k,mode=0700 tmpfs /space" which will allow up to 1 GiB in RAM/swap with 10240 inodes and only accessible by the owner of the directory /space. The filesystem's maximum size can also be changed on-the-fly, like "mount -o remount,size=2G /space". tmpfs /dev/shm http://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html /dev/shm is nothing but implementation of traditional shared memory concept. It is an efficient means of passing data between programs. One program will create a memory portion, which other processes (if permitted) can access. This will result into speeding up things on Linux. shm / shmfs is also known as tmpfs, which is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but one which uses virtual memory instead of a persistent storage device. If you type mount command you will see /dev/shm as a tempfs file system. Therefore, it is a file system, which keeps all files in virtual memory. Everything in tmpfs is temporary in the sense that no files will be created on your hard drive. If you unmount a tmpfs instance, everything stored therein is lost. By default almost all Linux distros configured to use /dev/shm. Nevertheless, where can I use /dev/shm? You can use /dev/shm to improve the performance of application software or overall Linux system performance. On heavily loaded system, it can make tons of difference. For example VMware workstation/server can be optimized to improve your Linux host's performance (i.e. improve the performance of your virtual machines). For example, if you have 32GB RAM then remount /dev/shm as follows: # mount -o remount,size=8G /dev/shm To be frank, if you have more than 2GB RAM + multiple Virtual machines, this hack always improves performance. # mount -t tmpfs -o size=5G,nr_inodes=5k,mode=700 tmpfs /disk2/tmpfs Well tmpfs is a type of filesystem which is pretty much as you describe. In fact it's cool because it stays in memory when there's enough available other wise it gets written out to your swap partition. This makes it noticably faster than normal disk access. The temp filesystem (or RAM disk, if you like) is created at the moment you mount it and destroyed when you umount it. You can define the max size with size=256m (for 256MB) as an arg to -o option on your mount command, or in the options field of /etc/fstab. The default size is half your total system memory. Well that's tmpfs. There's a tmpfs mounted at /dev/shm, but don't use that! That's for POSIX shared memory support (which hardly any programs use, yet, so you can seriously reduce the size of that in your /etc/fstab). Tmpfs is very cool to mount on /tmp, then you get very fast temporary files since they mostly don't stay around long they never need to be written to disk. You can actually mount a tmpfs on any directory you want and there are lot's of possible things you could do with it. For example, you could put together a system where some heavily-accessed read-only files/ programs are loaded from CD-ROM into a tmpfs at boot and accessed from there to have a lightening fast system (assuming you have lot's of RAM). Just remember, if your machine crashes, reboots, has a power failure, etc. even an accidental umount, and it's all gone without any undelete possibility. Don't save important data there, like the document you're working on for half a day.... However, this does make it extremely good for storing sensitive data before encryption. --> Not really. tmpfs may be pushed to swap space, where it could be recovered if the attacker has enough interest. Try running gnupg without suid root. It will warn you that it won't be able to lock the memory to RAM, and therefore may be recoverable. This is the same thing. I think you can do a kernel ram disk that resides only in the ram. It's definitely possible, since (normal) kernel memory isn't allowed to touch swap. In userspace you can pin the memory to RAM through mlock(2) (having permission do to so, which usually means being root). Another solution is to use an encrypted filesystem which you use for file you'll only need for a short time. This doesn't take as long as zeroing out (or filling with garbage) the swap partition. The main problem with these two approaches is that whilst you are editing your file, the memory that contains that file (the editor needs to have the file in memory) may be pushed to swap. I think there is the possibility of an encrypted swap which would solve all of our problems. You could have the memory in the editor pinned to memory, but I think that would require changing some shared libraries just for that one editor, so it's not worth the hassle. Then again, it depends on how secret your files are and/or how paranoid you are. Encrypted Filesystems: http://www.linuxfromscratch.org/hints/downloads/files/eswap.txt