Right now /tmp has some temporary files in it. When I mount my hard drive (/dev/sdc1) on top of /tmp, I can see the files on the hard drive. What happens to the actual content of /tmp when my hard drive is mounted? Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="87f7fef3efe8e9c7ebe6e9eeff">[email protected]</a> / $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 286G 43G 229G 16% / none 4.0K 0 4.0K 0% /sys/fs/cgroup udev 3.8G 4.0K 3.8G 1% /dev tmpfs 766M 1.4M 765M 1% /run none 5.0M 0 5.0M 0% /run/lock none 3.8G 38M 3.8G 1% /run/shm none 100M 24K 100M 1% /run/user /dev/sdb1 7.5G 2.7G 4.9G 35% /mnt /dev/sdc1 932G 242G 691G 26% /tmp
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
What happens to the actual content of /tmp when my hard drive is mounted?
Pretty much nothing. They’re just hidden from view, not reachable via normal filesystem traversal.
Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?
Yes. Processes that had open file handles inside your “original” /tmp will continue to be able to use them. You can also make the “reappear” somewhere else by bind-mounting / elsewhere.
# mount -o bind / /somewhere/else # ls /somewhere/else/tmp
Here’s a little experiment you can run to get a better (I hope) feel for what is happening.
Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.
I created a user called me on my machine, and a random directory in his home, with a file in it:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="315c5471595e5c54">[email protected]</a> $ pwd /home/me/tmp <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="e68b83a68e898b83">[email protected]</a> $ echo hello > some_file <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="58353d183037353d">[email protected]</a> $ ls some_file <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="234e46634b4c4e46">[email protected]</a> $ cat some_file hello
At this point, nothing unusual – it’s just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.
As root, I create a small filesystem and mount it over /home/me/tmp.
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b3c1dcdcc7f3dbdcded6">[email protected]</a> # dd if=/dev/zero of=./fs bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="c4b6ababb084acaba9a1">[email protected]</a> # mkfs -t ext2 ./fs mke2fs 1.42.12 (29-Aug-2014) [... snip ...] Writing superblocks and filesystem accounting information: done <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="6d1f0202192d05020008">[email protected]</a> # mount ./fs /home/me/tmp
I then open a new terminal as me, and look around:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b5d8d0f5dddad8d0">[email protected]</a> #2 $ cd tmp <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="066b63466e696b63">[email protected]</a> #2 $ ls lost+found <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="375a52775f585a52">[email protected]</a> #2 $ cat some_file cat: some_file: No such file or directory <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="78151d381017151d">[email protected]</a> #2 $ echo bye bye > some_file -su: some_file: Permission denied
So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it’s clearly not the original directory.
Back to the first me session, let’s look at how it sees the world:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="8ae7efcae2e5e7ef">[email protected]</a> $ echo something else > other_file
No problem writing.
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="2a474f6a4245474f">[email protected]</a> $ cat some_file other_file hello something else
Original file is still there, new file created without issue.
Huh? What’s going on?
The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn’t affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It’s sort of running around beneath the carpet mount point.
The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can’t use the requested space… lets fix that.
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="8dffe2e2f9cde5e2e0e8">[email protected]</a> # chown me:users /home/me/tmp
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="38555d785057555d">[email protected]</a> #2 $ echo bye bye > some_file <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="432e26032b2c2e26">[email protected]</a> #2 $ ls lost+found some_file <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="f19c94b1999e9c94">[email protected]</a> #2 $ cat some_file bye bye
Can session 1 escape from under the rug? (It’s getting musty.)
Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3b565e7b5354565e">[email protected]</a> $ cd <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="91fcf4d1f9fefcf4">[email protected]</a> $ pwd /home/me <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d8b5bd98b0b7b5bd">[email protected]</a> $ cd tmp <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="94f9f1d4fcfbf9f1">[email protected]</a> $ cat some_file other_file bye bye cat: other_file: No such file or directory
Same view as session #2, we’re back to normal.
But how do you know the files didn’t disappear? No one’s looking anymore!
That’s one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="28454d684047454d">[email protected]</a> $ mkdir ~/bind
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="285a47475c684047454d">[email protected]</a> # mount -o bind /home/me /home/me/bind
(Yes, you can bind-mount a filesystem “inside itself”. Cool trick, eh?)
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="e8858da88087858d">[email protected]</a> $ ls bind/tmp other_file some_file <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="79141c391116141c">[email protected]</a> $ cat bind/tmp/* something else hello
So they are indeed there, ready for action. It’s simply that they’re not visible/reachable at their original location, the mount hides them from normal directory traversals.
I encourage you to play around with this, it is really not complicated once you’ve understood the “trick” that is being played. And once you’ve Got It™, look into union filesystems for even more carpet pulling 🙂
One note though: mounting over /tmp or /var (or any of the core OS directories) really isn’t a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0