Linux and related systems offer plenty of possibilities for fast, efficient and devastating destruction. This document is no exception. With power comes dangers and the following sections describe a few more esoteric issues that should not be attempted before reading and understanding the documentation, the issues and the dangers. You should also make a backup. Also remember to try to restore the system from scratch from your backup at least once. Otherwise you might not be the first to be found with a perfect backup of your system and no tools available to reinstall it (or, even more embarrassing, some critical files missing on tape).
The techniques described here are rarely necessary but can be used for very specific setups. Think very clearly through what you wish to accomplish before playing around with this.
The hard drive parameters can be tuned using the hdparms utility. Here
the most interesting parameter is probably the read-ahead parameter which
determines how much prefetch should be done in sequential reading.
If you want to try this out it makes most sense to tune for the characteristic file size on your drive but remember that this tuning is for the entire drive which makes it a bit more difficult. Probably this is only of use on large servers using dedicated news drives etc.
For safety the default hdparm settings are rather conservative. The
disadvantage is that this mean you can get lost interrupts if you have
a high frequency of IRQs as you would when using the serial port and
an IDE disk as IRQs from the latter would mask other IRQs. THis would
be noticable as less then ideal performance when downloading data from
the net to disk. Setting hdparm -u1 device would prevent this
masking and either improve your performance or, depending on hardware,
corrupt the data on your disk. Experiment with caution and fresh
backups.
Most file systems come with a tuning utility and for ext2fs there is
the tune2fs utility. Several parameters can be modified but perhaps
the most useful parameter here is what size should be reserved and who should
be able to take advantage of this which could help you getting more useful
space out of your drives, possibly at the cost of less room for repairing
a system should it crash.
This should not in itself be dangerous, other than the peculiar fact that the exact details of the connections remain unclear for many drives. The theory is simple: keeping a fixed phase difference between the different drives in a RAID setup makes for less waiting for the right track to come into position for the read/write head. In practice it now seems that with large read-ahead buffers in the drives the effect is negligible.
Spindle synchronisation should not be used on RAID0 or RAID 0/1 as you would then lose the benefit of having the read heads over different areas of the mirrored sectors.