7. disksYour shopping list included a big disk. How do you split it up? What do you need now ? Later ? If you already have a DOS disk, you will need a second disk for Linux. If you can, use FIPS.EXE to reclaim 64 MB of the DOS disk for use as swap space, (makes your machine run faster, to use an otherwise unused disk). Then add your new disk and partition it with fdisk(8) fdisk /dev/hdb |
Hmm, this needs a bit of rewriting, but that takes time. 670 MB for most partitions. 10 MB boot at the start of the disk. 64 MB swap next to the main partition. Maybe 494 MB for an easy DOS life.
Remember that you are limited by the number of partitions (4) you can create, but one can be an extended partition, with another 4 in it (making 7). 2 of those are the swap and boot, so that's 5 which soon adds up to 3 GIG.
If you experiment with more than 4 extended, do that testing in the early days. It failed for me, and you don't want to have to do anything later, when you've forgotten what you can't delete.
Consider a swap file instead of a partition, or make the question even more complicated, by starting off with 2 disks, and plan to move them around later!
How big should the partitions be ? A good question, and nobody knows. If you create one huge partition, life is easier for a while, but gets more complicated when you want to trash (and rebuild) a half of the partition.
A minimal system, is something like a BOOT+ROOT diskette pair, debian uses 3 diskettes to hold it's initial image. That's less than 10 MB, and it is enough to do a Linux install, or mount other partitions.
If you are keen, you can install just what you need, and survive in (say) 100MB. You will learn a lot (relatively) quickly, but it's hard work. Personally, I like to "give a distribution a chance" and install all common packages, and several large ones, even if I never use them, chances are I'll encounter something I didn't realise was there.
Recently I tried a partition size of 350 MB, and got everything I wanted (initially), but it soon filled up and over! If you have a second partiition, move all of /usr onto it and be happy. Maybe 500 MB would have been better, or even 670 MB (and that means you can later use it for a CDROM image (or audio).
However, 300 MB is just enough as long as you only install exactly what you need, and don't need much.
I'd recommend that you expect to use 500 MB of a 670 MB partition, and get everything in there (ok not everything -- The CDROM was 645MB compressed!) Then news, email and src will gradually fill the rest, but that is several weeks away, giving you time to figure it.
When it is time to upgrade, you will want to build up the second system before deleting the first. You can multi-boot between them and avoid 'system down time', so remember to double book your requirements now (Planning!).
How big is a CDROM? Make that your partition size. In theory you can have 666 MB, but I've heard that 645 MB is a real limit. Make it 670MB, and never expect to create a CD bigger than 645!
You have a few main situations:
CD-Recorders are getting cheaper, and backup problems are a nightmare, so expect to get one next year (if not now).
If your partition is too small, you might have to rebuild your machine to make use of it. If it's too big, you will either be wasteing space, or hold more data than you can archive in one go!
If it really concerns you, create a dummy file that fills up the difference (eg a swap file) and add it to the mkisofs exclusion list.
A CD sized partition is a nice thing to have, and you don't need a CD-writer to take advantage of it. mkisofs will create images (on partitions), which you can mount just like a CD but faster. It's also read-only, so you can test things with it.
Remember that you need one partition to write to, and one collection of files to read from! They might be scattered, but it's easier to keep them in one place, which makes 2 or 3 x 670MB, but you only need them all temporarily.
So that's easy: take your 3.2 Gig disk. Subtract 10 MB for the boot partition. If you use DOS, allocate upto the 1024 cylinder limit (504 MB) for a DOS system that you can access from any config.sys (floppy disk boot), and then split the rest into 670 MB partitions, and don't forget a 64 MB swap partition adjacent to the root partition, or on another disk!
1024 (cylinders) * * 63 (sectors) * * 16 (heads) * * 512 (bytes per sector) / 1024 (bytes per KB) = 504 MB available under 1024
So if you have DOS:
10 MB boot
494 MB DOS
670 MB root
64 MB swap
670 MB CD-image
670 MB CD-files for the image
670 MB news / email / ftp / www / src / cache
3248 MB - TOTAL -
>
Initially, put everything on one partition, but at some time between installation and upgrade, expect to move all your files to a seperate (carefully backed-up) partition. That makes it easier to identify the files that you would be unhappy to lose. Even if you completely mess up the system files, you can reload them from CD, but your own files ? You can access your home partition from either the old, or new system. You probably only need 100 MB for your files (75 floppies!), but 350 is a reasonable number.
You will probably end up with a collection of downloaded packages, opened, compiled and with their own cache/data files. These can grow at any phenominal rate, so try to distinguish between things that came from CDROM (easily replaced) and things you had to download from the 'Net. That can reach 670 MB quite easily, but usually you can find something to delete (eg more recent version now available on CD).
When you do upgrade, you will be glad of another 670 MB, so that you can have 3 bootable systems: old + new_redhat + new_debian, just in case you wanted a choice.
You might also find that you can build a usable system in less, test it, then release the new partition for a more relaxed installation, with extra features.
When you've made up your mind, you can release two partitions, to act as CD-images, or news spools, or /usr/src/ caverns.
This is much more than you will need. 20 MB is possibly enough. You might anticipate getting several disks, with a bit of swap space on each. Personally I disable the swap space on the most used disk, to direct traffic away to the less used disks. (Comment out /etc/fstab)
When you are running the system, you can monitor swap space usage with free or top or one of the fancy X11 utilities.
You can always use swap_files, instead of swap partitions, but try to create them when the disk is fresh and unfragmented, not when it is full.
BIOS can only reach upto cylinder 1023, on the first two disks. This means that you have to take steps to ensure that all your boot files lie below this threshold.
Plan now, and create a small 10 MB partition below 1024. Use a boot floppy kernel until you get LILO working.
It is nice to be able to select which kernel to boot with, and what root partition it will use. Initially you start with 1-root + 1-kernel, but you plan for more.
If you don't want LILO to even touch your DOS disk, remove the DOS disk, replace it as the second disk, and install LILO on the MBR on the first disk. (See the SysBuild / fdisk /lilo.conf section). Then configure LILO so that it tells BIOS that disk 2 is disk 1 swapped (DOS needs this, becuase DOS can only boot from the apparently first disk). That worked for me with WIN.311 + DOS-5, but NT might be a bit more fussy. If you don't like it, simply replace the DOS disk as the primary disk, and it's MBR is intact, and now (back) in primary position on /dev/hda).
When you are running fdisk, you can select the partition numbers, but after that you end up with /dev/hdc2.
You could mount /dev/hdc2 as /home or /usr/local, but you don't. Instead you mount it as /hdc2.
You then create the dirs, and symb-links in place of dirs:
/usr/local --> /hdc2/local /home/gps --> /hdc2/home/gps /usr/src --> /hdc2/usr_srcIf you had mounted it as /home, you would now have /home/local, and a lot of files in the root directory of the disk (I have 4).
It is probably a good idea to create a list of all the symb-links that route to a particular partition, or just remember them.
locate README.fdisk (debian) it says that you can have 64 partitions. I failed to get 9, but suceeded to get 8.
It might have been something else altogether (the last partition that touches the end of the disk, had to be a plain one, not extended), I'm not sure, both changes didn't occur to me at the time, I just hacked until it worked.
Then subtract 3 from 8, you get 5 left. (Boot=10MB, Swap=64MB, extended=container). A 3 GIG disk / 5 is 600 MB each +- variety. Here's what I ended up with:
Disk /dev/hdc: 16 heads, 63 sectors, 6296 cylinders Units = cylinders of 1008 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/hdc1 1 1 20 10048+ 83 Linux native /dev/hdc2 21 21 426 204624 6 DOS 16-bit >=32M /dev/hdc3 427 427 4517 2061864 5 Extended /dev/hdc4 4096 4518 6296 896616 83 Linux native /dev/hdc5 427 427 1137 358312+ 83 Linux native /dev/hdc6 1024 1138 1267 65488+ 82 Linux swap /dev/hdc7 1024 1268 2892 818968+ 83 Linux native /dev/hdc8 2048 2893 4517 818968+ 83 Linux native
Notice how swap is in the middle, not too far away from anything else. Ideally this would be an otherwise unused disk.
When you are installing a new drive, it's obvious which one is which, ie the new disk is the shine'y middle one. One year later, they all look the same, and the labels are hard to read, without pulling the disk out!
Following the cable helps, but you might want to note down any visible labels, and also look at the kernels detected manufacturer label - see dmesg(8). At least then, you know that it's either the Seagate one or the IBM one. Alternatively draw a diagram, or write M/S on a small sticky label.
This figure is based around how much disk space gets used by an installation from CDROM. If you are left with a 1.7 Gig partition, use it, and have an easy life. If you expect to have several smaller partitions, consider 350, but you will need more than one!
Remember that 350 is about 10% of the disk, the idea being to make disk seeks times much quicker.
If you have a 100 MB ZIP drive, you might want to be certain that an entire disk exactly fits a partition. That makes it easy to copy-in a disk(-ette-) verbatim. Make on-line changes, and copy it out verbatim (if you think that is a good idea).
With extended partitions, you can have a few of these, or you can use a 100 MB file as a virtual partition. I think that needs the loop device (not tcp loopback), to access the files whilst not on the ZIP.
If you create a partition of say 800 MB, you can use it as a block-for-block copy of a CDROM (or a file by file copy). That allows you faster access to your favourite cdrom, and have a second one in the drive. Later, you can reuse that partition as you choose.
Note: 800 > 660, as some is needed for overhead.
To make that work, use dd(1) to copy the CDROM track to the partition, and edit /etc/fstab to say iso9660, as you would expect. Note CDROM's vary in length, some are 645, some are over 670 MB.
If you have so many disks, that you don't know what to do with them, fdisk them with one main partition. Then you only have to go around every once in a while, deleting out of date cache directories, or run-away files.
If you have a large newsfeed, or a run-away http cache, the disk may fill up, with the news directory flooding the rest of the system, preventing the arrival of email.
That is why you have individual partitions, and use the df(1) command.
Personally, I don't like "virtually concatenated multi disk devices", because if one physical partition breaks, you have to scrap and rebuild them all.
However, it is useful for ISP's who want a huge news spool directory, or collections of users WEB pages, that are best served from a single machine. The real problem is backup.
If I had a 1.3 Gig disk for Linux (no space allocated for DOS), I would consider carving it up as follows:
boot: 10 - /boot user: 350 - next OS or /home/gps swap: 60 - swap rest: 850 - root system ------------ Total: 1270 ------------
The 350 MB gives a place to play with other distributions, or use as your home directory (You have to save 100 MB of it when you try out a different distibution.
Users with one 1.7 Gig disk (and no DOS) might prefer several partitions, instead of the 800 MB one. Then you can allow news to run riot over one partition, you ftp files and untar them until you overflow your partition, and you still have a stable partition with your own stuff (which you can't delete ?).
That way you KNOW that an overnight news overflow, won't kill your email collections or mailing-list archives.
If you want the upgrade-97 partition to remain deletable, you can either not mount it, use it for your temp web cache, or to hold things from CDROM. If you haven't mounted it in the last month, you know you don't need it.
boot: 10 - /boot + vmlinux * 5 + backup config files root-ii: 350 upgrade-97 root-i: 350 current-96 swap: 64 news: 350 /var/spool/mail /var/9611/1130/an_ftp_file.tgz temp: 350 /usr/local /usr/local/src /usr/src /usr/docs /usr home: 100 /home/you save: 100 main archive diskette copy ------------ Total: 1674 ------------
Remember that 350 MB is only tight, if it is your only partition, and you can always trim down what you don't use.
I would avoid using the 'spare' 800 MB partition until last. If my disk is that full, I will need a CDROM to back it up (or a Jazz cartridge). In the mean-time, it is used for experimental installations, a complete copy of a CDROM, anything fun but immediately erasable.
In real life, you will probably have another disk, possibly 30 + 64 + 350 + 2.0 Gig. Remember to put the swap near the most used partition (or within it - as swap_files). Disable the swap on the busy disk.
If you have DOS, and it doesn't already have it's own disk, you will have to re-think the above entirely.
Smaller partitions fill up sooner, and get file fragmentation sooner. Fragmentation makes it slower.
Smaller partitions cover less of the disk, the head has less distance to move, when seeking files here and there. That makes it faster. EG 350 MB of 2000 is 7 / 40 or 17.5% or 1/6.
Provided you stay within the paritition (or if you are moving to an adjacent swap area), that is 1/6 of the distance for your disk head to move, potentially 6 times faster.
If you actively use those other partitions, you get no benefit at all, but somewhere inbetween x1 and x6 is the speed benefit that you do get.
Of course that is only the access time (10 ms = 100 HZ) not the read time (1000 x 4K per sec), and access time isn't exactly linear with seek distance, but you get the drift. If you just paid double for a CPU that is 20% faster, how much would you pay for a disk that goes twice as fast?