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 asymlink 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 oneto 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, wherereusing 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
Description: OpenPGP digital signature