[QtMoko] How do you manage your free space ?

[Dmitry Chistikov]

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)
exist.

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
/tmp
# 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
/tmp/a/a0/f
# realpath b/b2/f
/tmp/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.

[1]
http://git.altlinux.org/gears/c/coreutils.git?p=coreutils.git;a=blob;f=alt/realpath.c;h=5e8f50dbc4d10e02389a004178bb6ba606d0b2ed;hb=85e67589a5e9784918145d17200416afcea7d809 

[2] (in Russian)
https://bugzilla.altlinux.org/show_bug.cgi?id=25786

-- 
Dmitry Chistikov