[conspire] Partitioning revisited briefly
nick at zork.net
Thu Oct 14 03:57:39 PDT 2010
> Nick already aired his view in a 2010-09-06 post where he lead with
> conclusions and a some rather dismissive characterisations of people
> applying approaches different from what he recommended.
I dismissed only people who carved up partitions for historical reasons.
I mentioned the valid uses of trying out multiple distributions and of
using filesystems more prone to corruption. The dismissal of the
multi-distribution case has to be read in the context of the
conversation: I was editing documentation tailored to one supported
distribution, and which presented the multi-partition carve-up as a
rather distracting section in an otherwise easy-to-follow tutorial.
My later comments about keeping /home separate being no substitute for
backups were perhaps a bit glib under the circumstances. I stand by the
statement, although I appreciate it was not fully appropriate at that
point in the thread.
> Basic reading, by the way, should include FHS (http://www.pathname.com/fhs/),
> http://www.intelligentedu.com/linux_system_administration_course/ch03s02.html ,
> and 'man 7 hier'.
I heartily second this. The FHS description has managed to remain that
rarest of gem: a standards document that ordinary people can follow.
> $ ls -l /opt
> lrwxrwxrwx 1 root root 14 Mar 4 2008 /opt -> /usr/local/opt
> I've always considered the rationale for /opt (see FHS) to be dumb to
> begin with, and also redundant to that of the already extant subtree
> /usr/local. So, I made /opt a symlink to its own little ghetto within
> the /usr/local tree, such that it's not a nuisance and doesn't clutter
> up the root filesystem.
It does seem that /opt is the one piece of filesystem layout Ancient
History that did not really exist in common Free Software practice
before it was added to the FHS. I do kind of appreciate the reversal of
fortune where /opt/gnu is now /bin et al. and proprietary Sun junkware
is /opt, but that's cheap theatre.
> (Bear in mind that any symlink achieves its convenience at the cost of
> a performance hit (extra dereference) and the possibility of being
> mislead by a broken dangling link, if the referent goes away. I
> expect to use /opt as little as humanly possible, so the double lookup
> is of little concern.)
Consider also the effect of *absolute* path symlinks when a volume is
mounted in a new location in a tree. Say we were to plug a failed
system's drive into a host system for recovery work, and that this
hypothetical / volume had a symlink as above. Then (say)
/mnt/recover/opt would be a symlink *not* to /mnt/recovery/usr/local/opt
but to the *host* system's /usr/local/opt.
At some point several years ago I got into the habit of making all such
symlinks relative. So I would have something like this:
lrwxrwxrwx 1 root root 14 Mar 4 2008 /opt -> ../usr/local/opt
It can be confusing at first, (especially when you have to add three
layers of ../ or so) but I've found it helpful when sifting through
"Ill-informed qmail-bashing is better than no
qmail-bashing at all."
More information about the conspire