Disk tuning and partition decisions are difficult to make, and there are no hard rules here. Nevertheless it is a good idea to work more on this as the payoffs can be considerable. Maximizing usage on one drive only while the others are idle is unlikely to be optimal, watch the drive light, they are not there just for decoration. For a properly set up system the lights should look like Christmas in a disco. Linux offers software RAID but also support for some hardware base SCSI RAID controllers. Check what is available. As your system and experiences evolve you are likely to repartition and you might look on this document again. Additions are always welcome.
There are a few more important things that are about to appear here. In particular I will add more example tables as I am about to set up two fairly large and general systems, one at work and one at home. These should give some general feeling on how a system can be set up for either of these two purposes. Examples of smooth running existing systems are also welcome.
There is also a fair bit of work left to do on the various kinds of file systems and utilities.
There will be a big addition on drive technologies coming soon
as well as a more in depth description on using
fdisk or cfdisk.
The file systems will be beefed up as more features become available
as well as more on RAID and what directories can benefit from what
RAID level.
Recently I received an information pack from DPT, who made the first hardware RAID supported by Linux. Their leaflets now carry the familiar penguin logo to show they support Linux. More in-depth information will come soon.
There is some minor overlapping with the Linux Filesystem Structure Standard that I hope to integrate better soon, which will probably mean a big reworking of all the tables at the end of this document. When the new version is released there will be a substantial rewrite of some of the sections in this HOWTO but no release date has been announced yet.
When the new standard appear various details such as directory names, sizes and file placements will be changed.
I have made the assumption that the first partition starts at track 0 and that this track is the innermost track. That, however, is looking more and more like an unwarranted assumption, and not only because of the logical re-mapping that takes place. More on this when information becomes available.
As more people start reading this I should get some more comments and feedback. I am also thinking of making a program that can automate a fair bit of this decision making process and although it is unlikely to be optimum it should provide a simpler, more complete starting point.
It has taken a fair bit of time to write this document and although most pieces are beginning to come together there are still some information needed before we are out of the beta stage.
/tmp and /var/tmp has been hard to
determine, in fact what programs use which directory is not well defined
and more information here is required. Still, it seems at least clear
that these should reside on different physical drives in order to increase
parallelicity.
Now and then people post on comp.os.linux.*, looking for good project ideas. Here I will list a few that comes to mind that are relevant to this document. Plans about big projects such as new file systems should still be posted in order to either find co-workers or see if someone is already working on it.
that can automate the design process outlines earlier would probably make a medium sized project, perhaps as an exercise in constraint based programming.
that take the output of the previously mentioned program and format drives in parallel and apply the appropriate symbolic links to the directory structure. It would probably be best if this were integrated in existing system installation software. The drive partitioning setup used in Solaris is an example of what it can look like.
that keep an eye on the partition sizes and warn before a partition overflows.
that safely lets you move old structures to new (for instance RAID) systems. This could probably be done as a shell script controlling a back up program and would be rather simple. Still, be sure it is safe and that the changes can be undone.