Re: Adding a new partition to an existing IDE HD? - SCO

This is a discussion on Re: Adding a new partition to an existing IDE HD? - SCO ; "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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Adding a new partition to an existing IDE HD?

  1. Re: Adding a new partition to an existing IDE HD?

    "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<


  2. Re: Adding a new partition to an existing IDE HD?

    Tony, Bela,
    Thank you both very much - I think you've given me everything I need
    and more and I appreciate your willingness to help.

    I'll also be pushing to put one of the "super tars" on there, probably
    LoneTar since I've heard good things about it in the past as well.

    Thanks!
    ajm


  3. Re: Adding a new partition to an existing IDE HD?

    fencepost wrote:
    > Tony, Bela,
    > Thank you both very much - I think you've given me everything I need
    > and more and I appreciate your willingness to help.
    >
    > I'll also be pushing to put one of the "super tars" on there, probably
    > LoneTar since I've heard good things about it in the past as well.
    >
    > Thanks!
    > ajm
    >


    Not intending to dissuade you at all; both Lonetar and Microlite are
    excellent products but since it costs nothing to look at both of them,
    and they don't interfere with each other in any way (other than if you
    had both schedule automatic backups), there's no reason not to look at
    both to see which one suits your personality better.

    Personally, I use the Microlite product for my own systems, but there
    are features in the Lonetar product that I wish Microlite had. No doubt
    any Lonetar user familiar with Microlite would say something similar
    about features they like in the product they aren't using: the point
    isn't that X is better than Y, but that X *meets your needs* better.

    My client base is apt to use either one: I don't care which, as long as
    they use one of them. Just take the time to investigate both, and since
    both of them are constantly changing, it doesn't hurt to go back every
    year or so and test drive the one you didn't choose.. if nothing else,
    you may find a feature you can beg your current vendor for..




    --
    Tony Lawrence
    Unix/Linux/Mac OS X resources: http://aplawrence.com

+ Reply to Thread