Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Derek Atkins sez: Really, the only advantage of having multiple, small partitions is if you have multiple disks (spindles). The e2fsck program can work in parallel across multiple disks. But it can only split up after it finishes the root paritition. So, if you have, say, two 18G drives, it would be faster to have a 'small' root on one drive and then more partitions on both. If you only have one drive, it really doesn't matter. IMHO. It would be interesting to know of any actual measurable performance impact of different partition schemes. I've attempted such measurements on several sorts of Unix systems, and so far there were never any measurable performance differences. If linux actually has some, it could be useful to know about them. I've seen two reasons for having multiple partitions, neither of which is related to performance. One is the technical limitations of disk controllers or BIOSes. Some of these just can't handle a partition more than a certain size, and if your disk is bigger, you have no choice but to partition it. The other reason for partitioning is to wall off the mail, news and log directories, so you can't get a "denial of service" failure when they fill the disk. This can happen very easily, even without any malicious intent, as we just saw with the Melissa virus/worm on Microsoft systems. Unix systems aren't immune to this, so it can be a good idea to partition these things off so when they fill their filesystem, it doesn't drag everything to a halt. A related topic: making /tmp a separate "RAM disk" partition can be a very good idea if you are interested in performance. Of course, this has little if anything to do directly with the question of how to partition your disk. But saying "Don't put /tmp on disk at all" can be a useful addendum to the subject. (Then you have the quandary of how to decide the tradeoff between memory for processes, kernel buffers and the /tmp filesystem.) - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |