Why /usr/local/etc???

[Matthew Seaman]

Gary Kline wrote:

> 	This may have been covered too-often before, buy why can't
> 	*everything* related to /etc hang off "/etc"?  I can create a
> 	symlink in /etc to /usr/local/etc named "loc" or "local".  
> 	Thing is, why this isn't done by default?

Mostly historical reasons.  The typical Unix filesystem layout was
developed in the days when disk capacities were measured in Megabytes
and they were a lot less reliable than they are today.  Hence it was
important to have a separate root filesystem small enough to fit on one
drive and containing everything needed to boot the system -- and ideally,
if your root disk failed, you'ld have a spare drive with identical
contents to fall back upon.  Other file systems were created generally one
to a disk and mounted as required -- so you'ld have separate /tmp, /var, 
/usr, /usr/local, /home etc. If the filesystem grew beyond what one disk 
could support, you'ld have to create and mount a new filesystem on another 
disk and move content onto it. RAIDing disks together to make larger 
filesystems was developed as a response to the limitations of the hardware
of that generation, but in those early days it was unlikely you'ld be able
to boot from a RAIDed partition. Failures of disks providing other
filesystems could be handled by recovery from backup, so long as you had
that basic and as minimal as possible bootable root partition.

Nowadays, the situation is turned on its head.  Disks are very much
larger than the space required to install the OS, and they are both
reliable[*] and pretty cheap.  Server class motherboards generally assume you're going to mirror a pair of disks together to provide resilience.
There are also any number of portable disk equivalents that a system can
be booted off in an emergency: memory sticks, compact flash, live CDs etc.
all generally big enough to hold a complete bootable system.

However there is no overriding reason to rearrange the filesystems.
Oh, there are arguments about "does the root partition still need to be
kept separate" (personally, I'd say no it doesn't: one big partition to
hold it all is much simpler to administer, but opinions differ) but
nothing that makes change imperative.

I do think that there is potential for some sort of rearrangement due to
the increasing popularity of virtualization and similar techniques, where
reusing filesystem content as far as possible pays big efficiency 
dividends.  I'd see filesystems divided into three classes depending on 
content:  generic -- user home directories, web content, databases, system 
sources, the ports tree etc. that you'ld want to share or be able to 
migrate across all instances; arch specific -- kernel, binaries, shlibs, 
/usr/obj, binary package collections which are tied to the CPU architecture 
and the OS version and finally instance specific --  configuration data (ie 
/etc, /usr/local/etc), log files, temporary and swap spaces.  It's not 
excessively difficult to make this sort of split with existing layouts,
but it is more complicated than it needs to be.

	Cheers,

	Matthew
 
[*] Well, compared to 20 years ago they are.

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080824/e6e06097/signature.pgp