Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 6 down vote favorite
1

I'm wondering how other people feel about forward symlinks: are they safe? Good practice? Depends?

The reason I ask is that apparently in the linux desktop world, there seems to be a push by various distros to combine /usr/bin with /bin.

I've asked why but haven't gotten any great answers other than being able to do an "exec" call to load programs and not have to search PATH (which, to me, seems a rather inconsequential thing to do).

So they don't want to search path and always use /usr/bin/ -- ok, why not just put symlinks in /usr/bin pointing back to /bin? (FWIW, it's not just "bin", but also sbin, lib and lib64).

Instead of using backlinks, my current current distro has chosen to move binaries off of the root partition onto/into /usr and, as they move files from /[s]bin and the libs to /usr/[s]bin, they are putting forward-links from the root-based dirs to the files in /usr.

I have gotten no reasons, at all, for why they decided to move things from the root partition to /usr, but I thought it was common sense, in the case of critical files (like those needed for boot), to never use links to a file-system that might not be mounted by the time you can reference the symlinks.

I.e. links in /usr to root are safe because you can't mount /usr if you don't have a root! But the other way around... moer than once I've restored /usr from backup or hand-fixed some problem solely from the rootfs.

Am I being overly conservative or are forward link now considered to be in the realm of 'good practice' for critical files??

share|improve this question
I have never run into a system with /usr on its own partition... since it is for userland tools which are necessary to get to the system booted (just like /etc contains config files), I don't see why you would do this. In which case, symlinking would be find. Is it common to slice /usr into its own partition? – Matt Apr 17 at 23:13
1  
I certainly mount /usr as a separate partition occasionally. – fukawi2 Apr 17 at 23:38
1  
Mounting "/usr" separately, isn't as common in the desktop world, but used to be standard fair in the serverworld (where this was first posted). Servers need higher reliability and often don't boot to a GUI or 'X'. – Astara Apr 19 at 19:47
@Matt: So you've never used OpenBSD? – Martin Schröder Apr 23 at 20:55

migrated from serverfault.com Apr 18 at 14:47

3 Answers

up vote 2 down vote

The argument is that figuring out where a given binary should be ( / or /usr ) is needless complication that serves no purpose. Systems have already not been able to boot without /usr for some time now so there is no longer a reason to keep two directories.

See http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge for more details.

share|improve this answer
"Systems have not been able to boot without /usr for some time now"? – Astara Apr 19 at 21:10
You might want to qualify that. What do you mean by "boot" and what do you mean by "Systems". Certainly some systems is a more appropriate statement that just "systems". But that also depends on what you mean by 'boot'. More specifically -- Boot is anything it takes to get the machine to run-level 1. -- single user with networking no services other than, perhaps sshd. So what is needed on /usr for that to happen? Now If you want to call "starting services" and starging a graphical user interface" "boot"... You might as well toss in starting up facebook, etc. – Astara Apr 19 at 21:17
BTW -- having glanced at that webpage (last time I looked it was down).. I see alot of myths called fact and facts called myths. One can make any argument one wants if one allows calling "black", "white", and vice-versa. Wasn't it Orwell that called that "newspeak".. – Astara Apr 19 at 21:19
@Astara, udev has relied on numerous components in /usr for some time, so even single user mode can not function without it. systemd requires /usr as well. – psusi Apr 19 at 21:56
Apparently my server uses none of those components...as it has booted from a hard disk and mounted /usr/ during the boot phase for >10 years -- what components on a typical server using a text console would you have in /usr? and on what dist/os? – Astara Apr 20 at 0:30
show 6 more comments
up vote 2 down vote

A better reason for extensive (careful) use of symlinks...

Symbolic links do for filesystems (a kind of hierarchical database) what foreign keys do for relational databases.

With judicious use of both "forward" and "backward" symlinks (though I've not heard them referred to that way before), a distro could be designed where most things in /etc, /bin, /lib, and /sbin are symlinks to /usr/etc, /usr/bin, /usr/lib, and /usr/sbin. There could then be multiple versions of the /usr directory mounted someplace like under /initrd (initialize ramdisk). The filesystem could then manage, through careful creation and deletion of symlinks, which version was being used for each file at any given time.

Puppy Linux and some other distros use the unionfs and aufs filesystems to implement a variation of this concept.

The original O/S, as distributed, is kept static (unaltered) in permanent storage as a "bottom layer". When one of the files, such as /etc/hosts for example, is edited and saved, instead of changing the original, the filesystem creates a new copy in the topmost "working layer" on ramdisk. The filesystem then presents this copy, instead of the original, to the user.

The ramdisk copies are periodically (root user configurable) flushed in the background to a third layer which is also on permanent storage. Altered, ramdisk copies effectively overlay their saved versions which in turn overlay the static originals. Only the topmost copy is visible (for an unaltered file, this would be the original) so the file system looks completely typical to the user and other software.

This technique improves system speed and reliability...

  • User-initiated file reads and writes are very fast since they always use ramdisk.
  • Since the ramdisk layer only contains files recently altered, it stays small and functions like another cache.
  • Flush to slower permanent storage is deferred to background processing.
  • Copies can be made periodically of the "savefile" third layer, thus providing an "undo" capability for when configs or installs go wrong or malicious programs are detected.

Symlinks are what make all of this possible.

Answers to Questions...

How "high speed" is your setup?

The more memory you can give it, the more program can be kept in the ramdisk and thus the more responsive it will be. Starting a program from ramdisk is a bit faster than starting it from flash-memory (flashdrive, SD, etc.) and only takes a tiny fraction of the time needed to start the same program from a hard drive.

On my 300MHz 1999 Toshiba 4030CDT laptop with 64MB RAM, Puppy Linux 5.2.2 Wary, mostly based on Slackware, there's no room for much ramdisk so programs load from hard drive. Still, the 2D-GUI is quite responsive. I use it as the "console" connected via Synergy to all the other hosts.

At the other end of the scale is what I'm using now (via the laptop)... a Compaq S6010V running a 2.6GHz Celeron processor and 1.3GB RAM. The ramdisk "PuppySpace" has been allotted 512MB of which less than 200MB is currently in use. Loaded are Zim (a Python note-taking app), Geany editor/IDE, a terminal client with 5 sessions open, and 2 copies of Chromium with a total of 12 tabs of web pages active including Gmail.

how long does it normally stay up?

Because I'm constantly developing and changing configs, planned reboots are common. The uptime output for the Compaq is currently...

16:21:10 up 4 days,  7:28, load average: 0.06, 0.24, 0.30

Is it easy for the user to compile their own kernel from kernel.org and boot with it?

I can't address that as I've never done it. Though the Puppy Linux community is full of people that compile their own kernels for breakfast.

Is it something you run servers from?

All my systems are running either JWM or Openbox window managers (GTK+ based) but some work has been done setting up Puppy as a server as with LEMP and the Simplified Music Server Jukebox (mpdPup).

aufs? ...what's it good for? (over xfs/ext.

Aufs is a complete rewrite of unionfs. They both implement a union mount where multiple filesystems like xfs, ext3/4, etc. are mounted to the same mountpoint so they overlay each other.

share|improve this answer
I'd say correction: using symlinks is one possible way of implementing something like that. – Michael Kjörling Apr 19 at 19:28
I'd say you have a different problem space. You are running off of a root ram-device where everything is rooted in ram. How "high speed" is your setup" .. how long does it normally stay up? Is it easy for the user to compile their own kernel from kernel.org and boot with it? Is it something you run servers from? This was posted in the server forum initially, because the sytem I was talking about is a server that doesn't start a GUI -- just services. I've wanted to test and play w/unionfs -- aufs? Don't know anything about that one though...what's it good for? (over xfs/ext<N>... et – Astara Apr 19 at 21:30
up vote 0 down vote

Right now it's best to not make /usr a separate partition anymore. This way there is no need for symlinks at all.

At least, that's what I decided after the problems with binaries moving around started in my distribution. It actually makes a lot of sense to me, to have all binaries and libraries on the same partition. It doesn't matter then which are in /bin and which are in /usr/bin, and they can be moved around as you please.

The only reason I had a separate /usr in the first place was that I simply made a partition for everything; with LVM, it's easy to do. However apart from that, there was no practical reason for it. It was separated for the sake of separating.

If you have a partition for everything, your root / partition will be pretty much entirely empty. In my case it was less than 200MB. So I merged it with the /usr partition and freed the space previously uselessly wasted by the root partition. So far I have not discovered any downsides.

The merging process from a rescue system: (use at your own risk - may break your system)

mkdir /mnt/root /mnt/usr
mount /dev/lvm/root /mnt/root
mount /dev/lvm/usr /mnt/usr
# /usr will be mounted as /, so move everything into a new usr/ subdirectory
mkdir /mnt/usr/usr
mv /mnt/usr/* /mnt/usr/usr/
# copy the root files, preserving hard links just in case
rsync -aH /mnt/root/. /mnt/usr/.
# update fstab: comment /usr, change UUID of / to the one of /usr
nano /mnt/usr/etc/fstab
umount /mnt/root
umount /mnt/usr
lvrename lvm/root lvm/oldroot
lvrename lvm/usr lvm/root
# chroot to see if it works and update grub UUID
mount /dev/lvm/root /mnt/root
mount -o bind /dev /mnt/root/dev
mount -o bind /proc /mnt/root/proc
mount -o bind /sys /mnt/root/sys
chroot /mnt/root /bin/bash
update-grub # may depend on distro/bootloader
share|improve this answer
Ok -- question about the above -- the systemd page recommends getting rid of initrd in order to optimize boot time. I have been running w/o a initrd for -- "forever"... (I tried it, and it made debugging boot problems near impossible)...so does the above work with without initrd -- as having to load a bunch of utils from my hard disk onto a ramdisk in order to boot the system where where those utils worked in the first place seems a bit silly for a single user (for a distro that can't predict HW, that makes sense but...)... – Astara Apr 19 at 21:24
If your /usr is on LVM, the above would result in a root on LVM setup. Which is usually booted using Initramfs. As for boot time, there should be no big difference. It takes time to scan and enable LVM volumes; but whether that happens at Initramfs stage or real root stage, doesn't matter. If your Initramfs significantly slows boot time, something's wrong. – frostschutz Apr 19 at 22:29
it depends on what you mean by significantly. If we want to talk %, yes, if you are talking about "Commander Data" for whom milliseconds are an eternity... or your average computer" then likely, if you are talking Hawaiian time or Jamaican time? Likely not. But 25-100% slower isn't out of the question. – Astara Apr 20 at 0:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.