Re: debian install and multiple partitions
At 11:19 PM 12/24/99 -0700, Howard Mann wrote:
>Matt Garman wrote:
>> Now I want to split up Linux into many partitions,...
>I used cfdisk...
Here are some things I remember.
You will need to figure out beforehand if you want to leave room for more
than one operating system on your disk. IMHO, this is very smart to
do. I defined three 200 MB partitions at the beginning of my
disk. I installed Debian into the first partition and defined the
other two as /wrk01 and /wrk02. At this time I use them for spares
but, whenever I want to play, I will be able to load other OS's
(BSD, Rhat, etc.). This issue here is that all the bootable OS's
must be in the first 1024 cylinders. Some OS's may have removed
this restriction, but the strategy must accommodate the least
featured. The 200 MB is adequate to install a fully featured
version on any of the OS's I have ever played with. Ya know, it
occurs to me that I never verified that 600MB is within the first 1024
cylinders--it would be amusing if I goofed on that issue.
As I mentioned, I use /wrk01 and /wrk02 for spare, potentially bootable
partitions. I also define /wrk03 as a spare partition of a size
larger that any other partition. In my case, around 3GB as /wrk03
means that I have a place to work with the contents of any other
partition.
One of the tricks I use is to have a partition on a 2nd hard drive where
I backup a copy of my critical files. That way, if one disk were to
crash I would have a backup hard disk. I have even considering
writing a backup script that would mount the backup partition, do
the disk to disk backup, and then unmount the partition--this would means
that even if a stupid root user were to wipe everything out, my intra-day
backup would be preserved. This is a suitable backup strategy
for multiple times per day but does not alleviate the need for off-line
backup--it is just an extra safety measure that I have been doing for
years. I am putting together a network in my home office and I will
also backup to multiple machines. I lost everything one time, many
years ago, because of a disk crash so now I am very careful on
backups.
There is a definite advantage to multiple disks. There is also a
performance strategy to one disk or multiple disks, which is why the
multi-disk HOWTO is worth reading.
The thing I found most confusing was the issue of physical versus logical
partitions. Let me explain the issue as best I remember it.
On a physical disk you can have 4 physical partitions. The first 3
can be bootable (only one at a time) and the last physical partition is
an extended partition that can contain up to 15 logical partitions (63
with SCSI). That is plenty of partitions for any one disk.
Only a partition fetishist would feel cramped.
As I mentioned above, I use the first 3 physical partitions (200 MB each)
as bootable partitions for operating systems. In the 4th partition
I start defining logical partitions. The swap file CAN be in the
extended partition. The performance "science" of disk
layout is as follows. While it is true that the inside cylinders
and the outside cylinders have different transfer rates, to this date I
ignored that issue in favor of the following strategy.
Remember the boot partition, way at the other end of the disk. It
is going to take a long time to get over there if we are sitting in the
middle of the extended partition so we want infrequently used files
there. Our goal is to ascertain the frequently accessed parts of
out file system and cluster them in the extended partition. The
multi-disk HOWTO has some guidance in this area. Consider your
first partition strategy as your learning experience about how your
partitions perform for you. Once the partitions are laid out, they
will teach you about your usage patterns. I try to optimize for the
things I do most often.
In the past I placed my most frequently used partition in the middle of
the extended partition and clustered the other partitions around it,
based on frequency of use. I would kind of kind of cluster the left
side and the right side based on two different usage patterns--day to day
usage on one side and development on the other. I no longer favor
this strategy.
I mentioned before, about the inside versus outside performance
difference. My next strategy will be to position my most frequently
used partition nearest to the faster end of the disk and the other
partitions will be ordered from there in descending order by frequency of
use. I have not done the math to predict which would be better, but
my sense is that the latter strategy is better.
If any other tips occur to me I will post them later.
Lyno
Reply to: