News Group Posts

merging two partitions osr5

Main Index

From: Bela Lubkin <filbo@armory.com>
Subject: Re: Adding a new partition to an existing IDE HD?
Date: 15 Jul 2005 16:52:06 -0400
Message-ID: <200507151352.aa05592@deepthought.armory.com> 
References: <1121444933.597820.279780@g49g2000cwa.googlegroups.com> 

"fencepost@gmail.com" wrote:

> I'm keeping an eye on a 5.0.5 box with a HD that was getting touchy, so
> we migrated to a larger drive the simple and easily-backed-out way -
> DOS boot floppy, Ghost the disk off across the network, swap drives,
> restore image. SCO didn't have problems because both the old and new
> drives were using Large mode addressing in the BIOS - as far as it's
> concerned the available space after the active partition simply became
> larger.
> 
> What I'd like to do is create a new partition in that empty space and
> add it to a new mount point (/mnt/backup most likely since we'll be
> doing a nightly tar of some key files to it then ftping them off for
> backup). Any files being created would be strictly temporary and could
> be pretty large, so I'd rather not be putting them on the same
> partition as everything else - if the partition fills I'd rather just
> have a temp partition full.
> 
> I have the new drive in, I have a new partition created, what I'm
> uncertain about is what I need to do to create a filesystem on it and
> mount it. Unfortunately (from my view) the existing /dev entries that
> get mounted are of the /dev/boot and /dev/usr2 variety instead of the
> /dev/hdxy format that I'm a bit more used to which means I don't have
> good examples to work from.
> 
> So the questions I have are:
> * Do I need to create a new entry in /dev for the new partition on the
> same HD?
> * How do I do so? I might be missing something or it might be going
> past me since my past experience has been with other systems, but the
> documentation didn't seem particularly useful - are there particular
> magic numbers that I should be using with mkdev?
> * Should I just forget this idea, remove the new partition and tell
> fdisk to "Use entire disk for UNIX"?
> * If I do the above am I correct that it will nondestructively resize
> the current partitions to take advantage of the additional space?
> 
> The current fdisk -p output looks like this:
> 1 245565 952559 706995 UNIX Inactive
> 4 1 245564 245564 UNIX Active
> 
> and divvy reports this (annotated by me):
> 0              0          19999 (boot, EAFS)
> 1          20000         117999 (swap, non-FS)
> 2         118000        2000000 (root, HTFS)
> 3        2000001        7718749 (usr2, HTFS)
> 6        7718750        7718759 (recover, non-FS)
> 7              0        7735265 (hd0a, whole disk)
> 
> I'm assuming the hd0a is referring simply to the partition in question.
> I'd be looking to create hd0b, but since there are also entries as
> hd00-hd09 and hd0d I feel like I might be missing something. I believe
> the hd1x entries below are for the CD-ROM drive but I've never actually
> needed to use it and haven't explored that.

Start by reading the man pages hd(HW) and divvy(ADM).  Well, skim
hd(HW)...  It covers the meanings of the /dev/*hd* device nodes, plus a
lot of other stuff that's irrelevant to you.

The 'a' in "/dev/hd0a" refers to the "active" partition; there is no 'b'
like in Linux.  The '0' refers to drive number.  "hd01" through "hd04"
are the primary partitions of drive zero, referred to by absolute
partition number; "hd0a" is effectively an alias for one of those (hd04
in most cases).

Your new partition appears to be hd01.

Two of the many ways forward:

1. Create divisions on the new partition, and filesystems on the
divisions:

     divvy /dev/hd01  # use s[tart], e[nd], n[ame], c[reate]
     mkdev fs         # to set filesystem(s) to be mounted at boot time

2. Or, expand your current root partition, then use divvy and mkdev fs
to add divisions.  You have room for 3 more divisions in your root
partition.  If, as you suggest, you told fdisk "Use entire disk for
UNIX", it would _probably_ cleanly take over the entire disk, without
any harm to the existing divisions and filesystems.  This is true in
your case because the existing root partition starts at track 1, the
same place the "Use entire disk" function will anchor its output.
Still, you should not attempt this without a good verified backup in
hand.  (Perhaps we can assume that you still have the Ghost image and
that you already believe it is a sufficiently good backup, or your
entire project would be doomed...)

There are potential advantages and disadvantages to each route.

Splitting into two partitions means you have a full 7 division slots to
use on the new partition, while expanding the existing partition gives
you only 3.  This seems like a small advantage to me because the obvious
thing to do is make one large filesystem, which is undemanding of
division slots.

Expanding the existing partition would give you the opportunity to
expand your existing /usr2 filesystem.  The only thing standing in its
way is /dev/recover, which you can move to the new end of the partition.
The contents of /dev/recover are of no value except briefly during the
boot process (it's a temp area used by fsck during a crash reboot).
Having moved /dev/recover, you could expand /dev/usr2 using
ftp://ftp.armory.com/pub/admin/chfssize, as noted by Tony Lawrence.

Be aware that chfssize does not increase the size of the inode table.
Your existing 5.7GB /dev/usr2 was probably created with the default
ratio of 1 inode per 4K of filesystem space, or about 1.4 million
inodes.  If you expanded it to the full ~28GB, the filesystem would only
have enough inodes as long as average file size was over 20KB.

Realistically, that probably isn't a problem.  You're talking about
using it for huge backup blobs.

Even if you want to stick with your plan of having a separate backup
filesystem, merging the partitions probably makes sense.  You can expand
/dev/usr2 by a few GB while still adding a second /dev/backup
filesystem.  Surely you don't need 22GB of backup space for 7GB of
filesystems...  (It's good to have redundant backup on backup media --
multiple tapes or DVDs or whatever.  Pretty useless to have redundant
backups on the same point of failure -- the same hard drive -- as the
data being backed up!)

>Bela<
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.