24

Is there any practical difference between using ln -s or mount --bind?

I want to move some folders to another partition, without changing their daemon setting, and wonder what approach I should take.

I prefer ln -s as it requires minimum setup (no /etc/fstab modifications), but perhaps there is a reason why it's not common?

warren
  • 17,829
  • 23
  • 82
  • 134
SyRenity
  • 3,159
  • 11
  • 55
  • 79

4 Answers4

30

Hell yes. If you execute the ln -s you create a symbolic link, which is an inode pointing to a certain filesystem object, which is why symlinks can traverse filesystems and hard links cannot: hard links do not have their own inode.

If you mount a filesystem with --bind, you create a second mountpoint for a device or filesystem.

If you envision a symlink as a redirect, then envision a --bind mounted filesystem as creating another gateway to data.

Symlinks and bind mounts are a whole different ballgame.

The --bind mount seems a bit more robust to me and it probably is a bit faster than working with a symlink. On the other hand, there are no serious drawbacks to using the symlink, as the performance hit will be small (if it at all exists).

Edit: I've been thinking about this, and the performance hit might be a bit bigger than I originally thought. If you have an application that reads a lot of different files, then every new file that is opened will require an extra read. Some research here suggests that my assumption is correct, so if you have an IO heavy application running there, consider the --bind option to mount above the symlink solution.

The reason it is not common, is probably the fact that a symlink is visible in an ls, whereas a bind mount is only visible when looking at /proc/mounts or /etc/mtab (which is what the mount command does, if it is executed without parameters). Other than that, I don't think there are any issues. I'd be interested if there are, though.

Addition: another issue with ln -s is that for some applications, when the path gets dereferenced, it may cause the application to balk if it "expects" certain items to be in specific places.

warren
  • 17,829
  • 23
  • 82
  • 134
wzzrd
  • 10,269
  • 2
  • 32
  • 47
  • Thanks for the through explanation! A small follow-up question - what --rbind parameter actually does and how it can be used? From the manual it seems the parameter supports mounting the sub-mounts in the mounted tree is this correct? Also, is only --rbind enough, or I need to do --bind then --rebind? Thanks again. – SyRenity Dec 31 '09 at 13:53
  • Seems so. Never used --rbind myself. Try it out, I'd say ;) – wzzrd Dec 31 '09 at 13:57
  • 2
    `mount`, when invoked without any arguments, prints the contents of `/etc/mtab`, which has slightly different information than `/proc/mounts`. (In particular, `/proc/mounts` (symlink to `/proc/self/mounts`) always shows the mountpoints visible to the process reading it.) – user1686 Dec 31 '09 at 14:54
  • Oops. My bad. Fixed. – wzzrd Dec 31 '09 at 15:21
  • Wouldn't caching mostly eliminate any performance hit from the need to repeatedly traverse the symlink? – Ryan C. Thompson Aug 10 '10 at 01:36
  • Errr... @warren, feel free to rephrase my text if it is not clear, but if you have additions, please add them in a comment. – wzzrd Jun 07 '11 at 17:20
  • 1
    @wzzrd - from the [FAQ](http://serverfault.com/faq) "Best of all — edit and improve the existing questions and answers!" :) ..this is by no means a slight to your answer - it is a small improvement with additional information, for which you'll receive additional rep if/when it is voted up :) – warren Jun 07 '11 at 17:44
  • 1
    @warren, never mind, I'm not mad :) it's just you added something that I have no idea about, so that felt a bit odd ;) – wzzrd Jun 07 '11 at 18:03
  • 2
    @wzzrd - didn't mean to step on any toes :) ..the app-specific issue is something I've run into with the main product I use – warren Jun 07 '11 at 19:57
  • My user folders /home/userx are on a second disk volume, with a symlink for /home. Could or should I replace that symlink with a `mount --rbind /media/userdata/home /home` ? This might fix snap having issues with the symlink. – Roland Aug 28 '22 at 10:05
9

One of the big differences between ln -s and a bind mount is that you can use a bind mount to "modify" a read-only filesystem. For example, if there were a CD mounted on /mnt/application, and you wanted to replace /mnt/application/badconfigfile.conf with a correct version, you could do this:

mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf

It would not be possible to affect the same change using a symlink because you're not able to modify the target filesystem.

This can also be used to good affect if you distributed a common suite of software via NFS (or some sort of cluster filesystem), and you want to make host-specific changes on one system. You can simply use a bind mount on the target system to override the files or directories as necessary.

larsks
  • 41,276
  • 13
  • 117
  • 170
4

Practial difference #1 for me between ln -s and mount --bind :

vsftpd doesn't not allow to browse a directory through a symbolic link, but allows when mounted.

I don't know what daemon you're using, but it may behave similarly.

petrus
  • 5,287
  • 25
  • 42
2

One might note that as a consequence of binding to a mount, which is itself a binding, that is later rebound, the original binding remains intact, assuming everything physically stay connected.

That is, if bind A to B and bind B to C, and then bind D to B, C will still be bound to A. That might be what you want, or not. If one desires C to follow B then remount using the same targets, i.e. mount -o remount B C, or use --rbind instead. There is no --rebind option.

Ladadadada
  • 25,847
  • 7
  • 57
  • 90
Wiley
  • 121
  • 1