[conspire] Partitioning revisited briefly

[Nick Moffitt]

Rick Moen:
> 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
off-system backups.

-- 
"Ill-informed qmail-bashing is better than no
qmail-bashing at all."
        --Don Marti