| 2008-11-13 01:07:35 |
Daniel Hollocher |
debian-installer: statusexplanation |
@Philip
This bug (or feature request) is having /tmp and /var/tmp in ram instead of disk. This has never been the default (or an installation option). |
per discussion, its been decided that only /tmp should be mounted to tmpfs. /var/tmp should not be, since the data should persist beyond reboots. /tmp on the other hand, can be deleted on boot, since programs shouldn't expect files in /tmp to persist beyond the life of the program's process. |
|
| 2011-04-16 00:52:26 |
toobuntu |
description |
Because temporary files are temporary, there is no need to eventually write them
to disk. Tasks which rapidly create, alter, and remove temporary files will
have extra write-back cache flushed to disk needlessly (i.e. journals?), and
will incur checks in the file system driver to locate enough allocation space.
This can slow down tasks relying on heavy short term usage of /tmp.
I find that a more optimal configuration seems to be to use a tmpfs on /tmp and
/var/tmp, to avoid disk usage for short-lived files such as files being used by
apt or synaptic. The space on a tmpfs is treated similarly to disk cache,
except that it gets swapped out rather than invalidated; the decision to swap is
made under the disk cache rules.
Using a tmpfs, rapidly created, altered, and deleted files stay in memory until
removed, and space allocation is the much simpler task of checking how much
memory is available and how much is used in the tmpfs; in the worst case, longer
lived file data will swap out. Swapping is less intrusive than managing a file
system, so it is negligibly faster, though not noticibly. The avoided disk
access is nice, but also /tmp self-cleans on reboot and is almost absolutely
unrecoverable; a crypted swap partition would make it impossible to recover.
Below are fstab lines that set up a tmpfs on any amount of ram (1M, 256M, 4G,
etc). I always set it as 2G in size because that much will never be used; it
uses the same amount of memory no matter the value of size.
# temporary file systems
none /tmp tmpfs size=2G,nr_inodes=200k,mode=01777 0 0
none /var/tmp tmpfs size=2G,nr_inodes=200k,mode=01777 0 0 |
Because temporary files are temporary, there is no need to eventually write them
to disk. Tasks which rapidly create, alter, and remove temporary files will
have extra write-back cache flushed to disk needlessly (i.e. journals?), and
will incur checks in the file system driver to locate enough allocation space.
This can slow down tasks relying on heavy short term usage of /tmp.
I find that a more optimal configuration seems to be to use a tmpfs on /tmp and
/var/tmp, to avoid disk usage for short-lived files such as files being used by
apt or synaptic. The space on a tmpfs is treated similarly to disk cache,
except that it gets swapped out rather than invalidated; the decision to swap is
made under the disk cache rules.
Using a tmpfs, rapidly created, altered, and deleted files stay in memory until
removed, and space allocation is the much simpler task of checking how much
memory is available and how much is used in the tmpfs; in the worst case, longer
lived file data will swap out. Swapping is less intrusive than managing a file
system, so it is negligibly faster, though not noticibly. The avoided disk
access is nice, but also /tmp self-cleans on reboot and is almost absolutely
unrecoverable; a crypted swap partition would make it impossible to recover.
Below are fstab lines that set up a tmpfs on any amount of ram (1M, 256M, 4G,
etc). I always set it as 2G in size because that much will never be used; it
uses the same amount of memory no matter the value of size.
# temporary file systems
none /tmp tmpfs size=2G,nr_inodes=200k,mode=01777 0 0
none /var/tmp tmpfs size=2G,nr_inodes=200k,mode=01777 0 0
UPDATE:
/tmp could be on a tmpfs, but doing the same for /var/tmp would violate the FHS because /var/tmp is expected to persist after reboot and a tmpfs would not do so. |
|
