[QtMoko] How do you manage your free space ?
dd1email at gmail.com
Sat Aug 20 08:12:31 CEST 2011
Gennady Kupava, Aug. 06, 2011, 23:42 +0400:
> Also i think it's probably better to have
> single tree in fstab, not a graph of mounts until [...]
$ whatis fstab
fstab (5) - static information about the filesystems
I'd think a piece of information of this kind should be placed
exactly in fstab ;)
> Also you free to create,
> rename or remove symlink, while bind-mount is sligly more difficult to
To tell you the truth, I see only one difference between
ln <-> mount --bind, mv <-> mount --move, rm <-> umount:
before mounting, one is to make sure that mount points (directories)
Paths to files "under" symlinks are easily shown to be inherently
different: one is "real" ("absolute", see realpath(3) or realpath(3p))
and the other is not. For bind mounts, the same is not true.
# mkdir -p a/a0 b
# ln -s /tmp/a/a0 b/b1
# mkdir b/b2
# mount --bind /tmp/a/a0 b/b2
# touch a/a0/f
# realpath b/b1/f
# realpath b/b2/f
The realpath utility simply resolves a path with a standard libc
function realpath(3). Its source code can be found, e. g., at .
Note that while information on bind mounts can still be extracted
from /proc, filenames under a/a0 and b/b2 are equally "good" for all
reasonable userspace applications.
In rare cases, using symlinks for directories can result in strange
behaviour. Link  (in Russian) leads to ALT Linux Bugzilla and points
to a bug caused by a symlink /home -> /srv/home.
On the whole, I think that bind mounts are somewhat "safer" and less prone
And yes, a normal device mount, if possible, looks even better to me.
 (in Russian)
More information about the community