3

I am trying to install Ubuntu 16.04 on my 24Gb integrated SanDisk iSSD with another secondary 500Gb drive, as answered in: How to boot Ubuntu from SSD drive which cannot be selected as boot device?

Even though gertvdijk's answer is great, I still cannot understand the symbolic links that he mentions.

I want to make some folders that uses much space, for example /sbin/ to store the information on the larger drive instead. Lets say I make /sbin/ a symbolic link to /folder/on/large/drive/ with: ln -s /sbin/ /folder/on/large/drive

Will this do the trick? If I would use apt-get install to install a program and apt want to place files in /sbin/ would it automatically be placed in /folder/on/large/drive instead?

Or would mount --bind /sbin/ /folder/on/large/drive work better?

kung
  • 275
  • I personally use symlink in my home folder to Virtual Box's virtual machines while the actual folder is located on second hard drive. Works alright for that. I'd say it'll work, but if your second hard drive fails - you've no /sbin then – Sergiy Kolodyazhnyy Oct 17 '17 at 17:15
  • mount --bind as far as I know is used for mounting iso filesystems, so not used with folders typically – Sergiy Kolodyazhnyy Oct 17 '17 at 17:16
  • 1
    @SergiyKolodyazhnyy --bind is used to re-mount a directory from an already-mounted filesystem to an additional location. It's sometimes necessary to do that when mounting iso filesystems too, but mounting folders is specifically what it was designed to do. – Ethan Marmaduke Oct 17 '17 at 18:09
  • @EthanMarmaduke OK, thanks. I've not used that option outside of mounting my backuo isos, so it's nice to know it has purpose outside of that – Sergiy Kolodyazhnyy Oct 17 '17 at 18:19

1 Answers1

1

Short answer: Either one should work fine for that.

Longer answer: As long as everything works, they should function almost identically. The only difference would be in what happens if for some reason they don't work.

Think of a symbolic link like a "Shortcut" file. It's basically just a small file that tells you where to go next, and the OS (usually) handles that redirection for you automatically.

A mount, on the other hand, directly alters your view of the filesystem - whenever you request a file from a mounted directory, the kernel just silently hands you the actual file instead.

In the event that the target filesystem is ever unavailable, symlinks and mounts will behave differently. A symbolic link will point to a location that doesn't exist - and things will probably just start to throw errors. A mount, however, will immediately fail since there's no filesystem to mount. Then any attempts to read from or write to it will pass straight through to the (probably empty) directory that was supposed to be covered up by the mount.

Man pages: ln(1), mount(8)

All that being said, I would personally advise against moving any system-critical files (like /sbin) off the main drive. Moving /home (or some of its subdirectories) to a second drive, however, is a very common and accepted practice.

Ethan Marmaduke
  • 126
  • Is /home the only directory which is safe to move? After further research I was thinking of moving /home/, /opt/, /usr/local/ and /usr/bin/. Would any of these contain essential boot files or am I good? – kung Oct 18 '17 at 07:55
  • 1
    Those should be fine to move, too. I wouldn't recommend ever trying to move /bin, /sbin, or /etc. I'd be a little hesitant to mess with /var or /var/log, but /var/lib is fair game. – Ethan Marmaduke Oct 18 '17 at 16:00
  • 1
    Also, /dev, /sys, /proc, and /run can't actually be moved because they're not real filesystems, so don't worry about them. – Ethan Marmaduke Oct 18 '17 at 16:06