This is basically a section where I stuff all the bits I have not yet decided where should go, yet that I feel is worth knowing about. It is a kind of transient area.
swap and /tmp
Recently there have been discussions in the various linux related
news groups about specialized file systems for temporary storage.
This is partly inspired by the tmpfs on *BSD* and Solaris, as
well as swapfs on the NeXT machines.
The rationale is that these are temporary storage that normally
does not require much space, yet in normal systems you need to
reserve a certain amount of space for these. Elementary statistical
knowledge tells you (very simplified) that when you sum a number of
variables the relative statistical uncertainty decreases. So combining
swap and /tmp you do not need to reserve as much space
as you otherwise would need.
This specialized file system is nothing more than a swappable RAM disk that are swapped out to disk when and only when space is limited, thus effectively putting temporary files on the swap partition.
There is, however, a snag. This scheme prevents you from getting
parallel activity on swap and /tmp drives so under
heavy activity the system takes a bigger performance hit. Put
another way, you trade speed to get space. Interleaving across
multiple drives reduces this somewhat.
swap drives.
This is not striping across several drives, instead drives are accessed
in a round robin fashion in order to spread the load in a crude fashion.
In Linux you additionally have a priority parameter you can adjust for
tuning your system, especially useful if your disks differs significantly
in speed. Check man 8 swapon as well as man 2 swapon for more
information.
In many cases you do not need a swap partition, for instance if you have plenty of RAM, say, more than 64 MB, and you are the sole user of the machine. In this case you can experiment running without a swap partition and check the system logs to see if you ran out of virtual memory at any point.
Removing swap partitions have two advantages:
In the end, having a swap partition is like having a heated toilet: you do not use it very often, but you sure appreciate it when you require it.
/mnt
In an earlier version of this document I proposed to put all
permanently mounted partitions under /mnt. That, however, is
not such a good idea as this itself can be used as a mount point, which
leads to all mounted partitions becoming unavailable. Instead I will
propose mounting straight from root using a meaningful name like
/mnt.descriptive-name.
Lately I have become aware that some Linux distributions use mount points
at subdirectories under /mnt, such as /mnt/floppy
and /mnt/cdrom, which just shows how confused the whole issue is.
Hopefully FHS should clarify this.
Partitions are labeled in the order they are found, not depending on the SCSI id number. This means that if you add a drive with an id number inserted in the previous order of numbers, or change id number in any other way, the partition names will be messed up. This is important if you use removable media. In order to save yourself from some unpleasant experiences, you are recommended to use low numbers for fixed media and reserve the last number(s) for removable media drives.
Many have been bitten by this misfeature and there is a strong call for something to be done about it. Nobody knows how soon this will be fixed so in the meantime it is wise to take this into consideration when you design your system. For instance it may be a good idea to use the lowest SCSI id number for you root disk so that it has the least probability of being renumbered should one drive fail.
Not many years ago a machine with the equivalent power of a modern PC required 3-phase power and cooling, usually by air conditioning the machine room but some times also by water cooling. Technology has progressed very quickly giving not only high speed but also low power components. Still, there is a definite limit to the technology, something one should keep in mind as the system is expanded with yet another disk drive or PCI card. When the power supply is running at full rated power, keep in mind that all this energy is going somewhere, mostly into heat. Unless this is dissipated using fans you will get a serious heating inside the cabinet followed by a reduced reliability and also life time of the electronics. Manufacturers state minimum cooling requirements for their drives, usually in terms of cubic feet per minute (CFM). You are well advised to take this serious.
Keep air flow passages open, clean out dust and check the temperature of your system running. If it is too hot to touch it is probably running too hot.
If possible use sequential spin up for the drives. It is during spin up, when the drive platters accelerate up to normal speed, that a drive consumes maximum power and if all drives start up simultaneously you could go beyond the rated power maximum of your power supply.
This is an Internet system that no doubt most of you are familiar with. It searches and serves Usenet News articles from 1995 and to the latest postings and also offers a web based reading and posting interface. There is a lot more, check out Dejanews for more information.
What perhaps is less known, is that they use about 20 Linux SMP computers each of which uses the md module to manage between 4 and 24 Gig of disk space (over 150 Gig altogether) for this service. The system is continuously growing but at the time of writing they use mostly dual Pentium Pro 200MHz systems with 256 MB RAM.
A production machine normally has 1 disk for the operating system and
between 4 and 6 disks managed by the md module where the articles are
archived.
The drives are connected to BusLogic Model BT-946C PCI SCSI adapters,
usually two to a machine.
Just in case: this is not an advertisement, it is stated as an example of how much is required for what is a major Internet service.
There are many file system structures in existence, differing with
FSSTND (and soon FHS) to varying degree both in terms of philosophy,
strategy and implementation. It is not possible to detail all here,
instead the interested reader should read the relevant manual page,
man hier which is available on many platforms and implementations.
In the old days the file system used to take advantage of knowing the physical drive parameters in order to optimize transfers, for instance by endeavouring to keep a file within a single track if possible which saves track-to-track seek time. These days with logical drive parameters, drive cache and schemes to map out bad sectors, such optimizations become meaningless and might even cost more than it would gain. As most Linux installations use modern file systems these schemes are not used, however, some other operating systems have retained such schemes.