[QtMoko] How do you manage your free space ?

Dmitry Chistikov 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
> manage.

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.

# pwd
# 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 [1].

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 [2] (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
to errors.

And yes, a normal device mount, if possible, looks even better to me.


[2] (in Russian)

Dmitry Chistikov

More information about the community mailing list