Summary: Partitioning a 2 GB disk

From: Sally Roberts (
Date: Fri Aug 19 1994 - 14:26:05 CDT

A few days ago I posted a message asking about how to divide up a large
hard drive into partitions; basically, I was wondering if there were
any system administration concerns that would make one way particularly
desirable or undesirable. The original question was:

> I have a large (2GB) drive which will be added to my system, and I'm
> trying to decide on a way to partition it. This drive will hold two
> types of files: several large applications (GIS, mostly), and project
> files. The applications partition will need about 500M, and I'll
> probably just make that a single partition and be happy with it. What
> I'm wondering about is the projects section: should I just make it one
> 1500M partition? Or would I be better off to break it up, for instance
> into 3 separate 500M partitions? And if so, why?

What I decided to do was to skip partitioning the thing altogether, and
make the entire drive one large filesystem (a decision helped along by
my boss' consent to buy an 8mm drive so I could back the thing up at
a reasonable rate), thus simplifying everything and avoiding that annoying
situation where one partition is just a few megs too small and you've got
all this unused space on the others.

Many thanks to all those who responded; the answers I got follow.

Sally Roberts					Limno-Tech, Inc.
Environmental Engineer				2395 Huron Parkway,			Ann Arbor, MI 48104
Voice: (313)973-8300				Fax: (313)973-1069

* * * * * * * * * * * * * * * * * * From: (Richard Mitchell 1026)

Except for the internal disk (at least thats where I keep the O.S. and other system required stuff) I'm not sure there really is a good reason to partition the disk at all...unless you are trying to limit a group of files to a particular amount. If not, invariably you'll end up with a few meg short in one and oodles in the other.

We've got a few 4GB drives here and I did partition them into 2 parts so that I could move them from Solaris 2.3 systems to Sun O.S. 4.1.3 if needed. Other than that, I only put one partition on the drives.

* * * * * * * * * * * * * * * * * * From: Jeff Blaine <>

Do you have any idea what projects are coming up that the 1500 megs will need to be allocated to? A decision like this is really difficult to make not knowing exactly what kind of environment and data will be used in the projects. In my opinion, you're better off partitioning in say, 5 300 meg chunks. This way you don't waste a huge amount of space for something that only needs 100 megs, and you can expand other project areas if they need more space by mounting another 300 meg partition underneath the tree of an existing initial 300 meg partition.

* * * * * * * * * * * * * * * * * * From: Ed Trumbull <>

What are the criteria that you'll use to decide which way is better? My preference would be to stick the whole thing into one partition. I don't think that this will cause much performance impact (and might gain some depending on how the data lays out on the cylinders), and it's easier to keep track of, I think. (In fact, I'd probably just add the whole disk, and let the applications mingle with the projects.)

* * * * * * * * * * * * * * * * * * From: (Syed Zaeem Hosain)

My recommendation is to minimize the number of partitions unless there is some *very* strong reason to separate the way you propose to do.

1. Making multiple partitions makes backing up easier and tougher at the same time. Easier because the partitions can be then backed up separately and take less time per partition - you can even forego ones that don't change often. Tougher because you have to back them up separately and must make sure that your normal backup routines don't skip one or someone.

2. Total drive head motion is increased with multiple partitions. If you start with the single partition, files tend to stay closer together in general (certainly in the beginning) and the head moves less far to get to a particular file for a user. With multiple partitions, you are guaranteed longer seeks to particular locations for files spread about the disk in a maximally separated way.

This is, of course, a very minor optimization issue, and tends to degrade over time anyway as the partition gets fragmented with use. Performance does not suffer to badly (the fast file system) but head motion does increase.

3. When you run out of room in a given partition, but want to keep some use on it, and room is available on another partition, you end up having to backup the drive, re-label it and reload the files. Else, you end up resorting to kludgey pointers to the actual locations to keep consistency in your path and other accesses, and the environment and drive degenerates into a mismanaged chaos from there (I am only exaggerating a little bit <grin>) - you have to spend extra effort as a system admin person to figure out what you did the last time to fix some problem. "Keep it simple" is my motto.

4. If all the projects are similar, i.e. there is no real reason for the separation, then adding the complexity of addition mount points (perhaps from other systems) is not worth it. A minor point perhaps.

5. If some user needs to be able to get to multiple projects, that are not on the same partition, he/she now needs to remember and manage that information and search paths have to have multiple entries. Else, again, you will need to resort to some kludge pointer systems (and I have done this for multiple drive/server access situations) to provide consistent paths. If you are interested in an example of how I set up two servers and 8 disks for such consistent access - increased work for system admin for initial setup but less problems for the users - send me e-mail and I will explain.

IMHO, the bottom line is: use a 500MB partition for the applications and a 1500 MB for the projects.

* * * * * * * * * * * * * * * * * * From: (Szymon Sokol)

While 3 smaller partitions (or whatever number >1 you choose) may save some time during fsck, generally a larger partition is more useful, since it gives more flexibility (you do not have to juggle files between partitions as their usage changes).

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:08 CDT