Gaby vanhegan wrote: > Hi, > > I am still working on a nice automated installation CD system. It is > partially a custom boot CD and partially a site36.tgz file that > installs all the relevant packages, then does a scripted restoration > from out backup server. It's intended for bare-metal restores in the > event of complete disk or server failure, and should operate almost > totally unattended. > > The only problem I have left to overcome is that of automatically > partitioning the disk at the first stage of the process. I know that > I can read an existing disklabel to a text file, and write a > disklabel to a disk from the contents of a text file. My > configuration file for each server would have an entry like this in it: > > [partitions] > / = 15% > swap = 512M > /home = 10% > /root = 10% > /var = * > /www = 25% > /logs = 10% > /tmp = 5% > > The problem arises when, if going on to a brand new machine, that the > disk size may be different than the original it is restoring. As > part of the installer (in the OpenBSD install environment, booted off > an openbsd installer CD) I'd like to read the size of the disk and > partition the disk accordingly. would I need to generate all of this > information?
Using your strategy, you would have to generate the info. Here's a (I think) better idea... Rather than trying to partition out percentages, just put in what you need... / 100M swap 512M /usr 4G /var 1G /tmp 100M ... and so on. And (here's the shocker) leave the REST OF THE DRIVE UNALLOCATED! WHY should / change in size because the disk got bigger? How about /home? why would ANY partition change in size because the disk got bigger?? The partition is either big enough for the job or it isn't. Most modern hard disks are huge compared to what most users need an OpenBSD system to do for them. There is no reason to increase your fsck times just because you needed a 6G drive, and all you could find were 80G and larger. Somewhere along the lines, we decided that 100% of every disk should be allocated. That was never true, and certainly isn't getting more true. Now...here's another trick: leave the most likely to need to grow partition at the end of the disk -- for example, /var or /home. Now, if you run out of space on that partition, use growfs(8) to expand into the unused space (try that if you use the entire disk!). If one of your other partitions needs more space, create a new one in the unused space, and copy the old one to the new one, change fstab, reboot, and done. Benefits to minimal disk partitioning include: * Lower RAM requirements on fsck * Faster fsck * More ability to "adjust" partitioning later * clustering data in a small part of the disk decreases seek times * MUCH faster remirror if using software mirroring * (I'm sure I will remember more later) Nick.
