What happens to remounted data/directories

Question

According to suggestions in this post I am trying to improve my system to run better with a Solid State Drive. But regarding to RAMdisks and /etc/fstab usage I have some understanding problems coming up.

So let's say I add the following lines to /etc/fstab

tmpfs   /tmp       tmpfs   defaults,noatime,nodiratime,mode=1777   0  0
tmpfs   /var/spool tmpfs   defaults,noatime,nodiratime,mode=1777   0  0
tmpfs   /var/tmp   tmpfs   defaults,noatime,nodiratime,mode=1777   0  0
tmpfs   /var/log   tmpfs   defaults,noatime,nodiratime,mode=0755   0  0

I know that on startup these locations should now get mounted into the RAM (hopefully).

But what happens to the physical space that was mounted on those places before? Is it gone? Will it be back when I edit my /etc/fstab back to the Version without tmpfs? Will the space still be allocated on my SSD in a way that I can't use it for any other data?

Sometimes it is suggested to add the following line, too:

none /var/cache aufs dirs=/tmp:/var/cache=ro 0 0

What does this actually do? I noticed that /var/cache takes almost 1GB of space on my harddisk. So should i clear the directory before activating this line? (this is related to the former question)

This causes me some confusions and I hope you can give me some clarifications.

UPDATE
I've downloaded a image with 600MB in size into /tmp that is mounted with the tmpfs settings above. Now I wanted to compare the RAM usage before and after the download. I expect the RAM usage to be increased by 600MB after the download. But the System Monitoring Tool showed me no changes at all.

How can this be? Does tmpfs work other than I actually expect it to?

Answer 1

Mounts

When you mount a file system at a point in a file system, the previous contents become invisible for the duration of the mount and reappear when the mount is absent. They do consume space on the file system though invisible.

---

The question thread you quoted seems to have a lot of very helpful information. Maybe I can add a little information given your questions.

tmpfs

The contents of tmpfs file systems, as you mention, are not persistent--they always lose their data when the system is restarted.

While I know of no drawback for storing /tmp in memory (except for the memory it consumes), the FHS (Filesystem Hierarchy Standard) says that /var/tmp should survive reboots, so that shouldn't really be a tmpfs (mine is empty at this moment). /var/spool stores print jobs, and possibly other things. /var/log contains debugging information which is of no use unless you have a problem, but then may become very important. I wouldn't put any of these last three on a tmpfs, though I admit that the logs get a lot of writes.

aufs

I'm not sure, but I think perhaps the aufs mount is meant to allow one to read from /var/cache/ while actually storing anything you write to it to /tmp/ (which would appear in both /tmp and /var/cache/). I'm having trouble matching the fstab entry you mention in your question with the man page documentation I get with aufs-tools version 1:3.0+20111101-1ubuntu1. I wish the article you quote had more information about this particular item. If you decide to use aufs and have trouble with the syntax I'd suggest you try Andrew Ferrier's fstab entry from the comments in the question thread you quote as it seems to better match the documentation I was able to find.

/var/cache/apt/archive is used to contain .deb files for packages you have installed. If your system is like mine you will find a lot of the space here consumed by /var/cache/apt/archives. You can clean it out with sudo apt-get clean. A cache is useful for performance, but is supposed to only store replaceable items. The /var/cache/apt/archive cache allows you to reinstall versions of packages without having to download them again. If you want to reduce this space with apt-get clean you would need to do that when there is no mount on top of /var/cache so the data can be seen and removed from the device and that space recovered.

Other Items

The noatime option and related nodiratime option give up having the file system remember when a file is accessed (read), with the benefit that there are fewer writes to the file system, improving performance and reducing wear on the SSD. If you care about searching for files that have been read in a certain time frame you would lose that abiility. I don't find myself doing that.

I see some suggest setting an option on your ext3/4 file systems to turn off the journal, which constitutes a fair number of writes, at the expense of recovering some data you have recently written if your system goes down.

If you look here, oldfred gives two commands that can be used with SSD's in post #2.

sudo tune2fs -O ^has_journal /dev/sda1
sudo tune2fs -o discard /dev/sda1

changing /dev/sda1 as appropriate, of course.

The first turns off the journalling I mention above. The second tells the kernel to communicate the deletion of file information to the SSD's controller so it can more optimally manage the device, giving better performance.

My Humble Opinion

I think I would start with using tmpfs for /tmp, use the noatime mount option, turn off EXT4 journaling and turn on the discard option.

I agree with JR0cket and definitely wouldn't put a swap file on the SSD for fear of shortening its useful life.

I've made these changes to my flash drive and, due to the journal change, it has had to take a few more seconds to fix up my file system on boot, having had to reboot at least once. When I reboot or halt apparently the file sync hasn't completed before the system has halted or rebooted and after the last write to the file system. That hasn't been a significant problem for me and I haven't noticed any other repercussions from the other changes.

I hope someone who has done this before or who knows about aufs will contribute more details in answer to your question.

Answer 2

Beware of putting /var/spool/ on tmpfs!

User CRON JOBS are stored under /var/spool/ on Ubuntu!

If you put /var/spool/ on tmpfs you will not be able to have any user cron jobs because they will be erased on every shutdown.

The system crontab however is located in /etc/crontab and is edited directly NOT with the crontab -e command. found this out the hard way :-(