A.P. Lawrence

swapping a hard drive, hot swap, raid, divvy, badtrk

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Tony Lawrence <tony@pcunix.com>
Subject: Re: Swapping a hd in 5.0.6
Date: Mon, 11 Nov 2002 06:24:56 -0500 References: <20021108112935.A9421@egps.egps.com> <20021109164949.05596@tegan.com> <20021109193812.A24538@egps.egps.com> <20021109204029.17968@tegan.com> <20021110164846.A1171@egps.egps.com>

Nachman Yaakov Ziskind wrote:
> Problem solved. Thanks to everyone for your input.
> 
> [big snip of stuff we've all seen already. My problem boils down to this: after
> replacing a small hd with a bigger one, the old partition tables and
> filesystems were still visible, and the disk could even be written to/read
> from].
> 
> I wrote:
> | But what if fdisk shows the wrong number of tracks, and divvy the wrong 
> | number of blocks? What does one do then?
> 
> Tom Parsons wrote:
> | If fdisk shows the wrong number of tracks (are you sure), then you should
> | first determine if you are looking at the right hard disk.  It is rather
> | obvious that if fdisk doesn't display proper size, divvy isn't going to
> | display the proper size.
> | 
> | fdisk tells you what device node it is reading, does that correspond to
> | where you have the drive configured?  I guess it is possible the Compaq
> | controller might have the size of the drive saved somewhere.  I've seen
> | dumber...but not much.
> 
> I absolutely was looking at the right hard disk. First of all, since I used
> mkdev (for better or for worse) I only input the SCSI ID, which I could tell
> (in this Compaq setup drive ID is determined by the slot the hd sits in) and
> the mkdev script figured out the rest. Plus, I pulled the drive and watch the
> errors pile up. So, I did have the right drive.
> 
> Anyway, for the record, the real reasons I run badtrk are 1) because it's
> there, and 2) if there's an error, I want to know about it - another data point
> for my investigation. Unix is sparse enough with its messages that I don't want
> to throw any away!
> 
> Then Tony Lawrence wrote:
> 
> | Can we backup a second and go over what I think you had and what you
> | should have done?
> 
> | I think you had a 9 gig drive mounted somewhere.  If you did, for
> | example, "df -v" it would have shown up as one of your mounted
> | filesystems.  The device node would have been listed there also.
> 
> Yup. Yup. Yup.
> 
> | Lets say it was /dev/u2
> 
> | Run "divvy /dev/u2" just to see if you left any space there or have any
> | non-fs's you forgot about.
> 
> | Backup the directory it is mounted on.
> 
> Done all that previously - it was now empty of everything except lost+found.
> 
> | Then shutdown, replace the drive with the 72gb, and reboot single user
> | (single user so /dev/u2 doesn't try to mount).
> 
> | From what I read, it sounds like you followed this procedure or
> | something very close to it so far, am I right?
> 
> Except reboot into single user - I skipped this. I just umounted.
> 
> | Now run "divvy /dev/u2" again.  I think this is where you used "mkdev
> | hd", which is (as Tom said) perhaps unnecessary, but otoh it is also
> | completely harmless (assuming you answer things to make it so) and does
> | indeed lead you through the steps mentioned. And I said, running badtrk
> | may raise some eyebrows, but I still think its worth the time.
> 
> | However, when you got to the divvy part, it should have been blank.  If
> | it was NOT blank (which seems to be the implication here) then you
> | either were NOT looking at the proper disk or your system is very very
> | confused.
> 
> THAT was my problem. Both fdisk and divvy were retaining the old tables - even
> across a reboot.
> 
> | For a new drive, there shouldn't have been an fdisk partition either,
> | unless it was something from another machine or had been previously
> | used.  Was there?
> 
> It showed precisely the same numbers as before the swap. Same tracks, same
> filesystems, etc.
> 
> So, last night, while working from home, feeling dreary, pondering Tom's
> admonition to make sure I was looking at the right drive (and darn it, I WAS
> looking at the right drive), and then I saw it:
> 
> Current Hard Disk Drive: /dev/rdsk/3s0
> 
>         +-------------+----------+-----------+---------+---------+---------+
>         | Partition   | Status   | Type      |   Start |     End |    Size |
>         +-------------+----------+-----------+---------+---------+---------+
>         | 1           | Active   | UNIX      |       1 |  281774 |  281774 |
>         +-------------+----------+-----------+---------+---------+---------+
> 
> Total disk size: 2258025 tracks (256 reserved for masterboot and diagnostics)
> 
> At which point, I noticed the "Total disk size:" DUH! Perhaps the 'tracks' it
> is counting is not the same as the Start/End figures? I did some feverish
> reading on the fdisk man page and decided that, no, tracks are tracks, and
> fdisk is only looking at 12% of the drive. I selected "Use Entire
> Disk for UNIX", and (after a scary warning) got: 
> 
>         | 1           | Active   | UNIX      |       1 | 2257769 | 2257769 |
> 
> Which looked MUCH better. So, letting the dice roll, I ran divvy, and got the
> same division table as before, with one small difference:
> 
> 71111722 1K blocks for divisions, 8001 1K blocks reserved for the system
> 
> Which I picked up on right away. :-) I thought I'd just expand the last block
> of the first filesystem to 71111722, umount and mount, and away I'd go. 
> 
> But no, the filesystem stayed at 9gig in df -vk. After more head scratching, I
> decided to remove all the first division entirely, and reinput the numbers.
> Much happier! Divvy declared:
> 
> Making Filesystems
> 
> and mkfs sat there for a most satisfying five or ten minutes, and I was now up
> to 73gig, Woo-hoo!
> 
> So, where was OpenServer getting its copies of the tables from? I refuse to
> believe the the Compaq Proliant SCSI system is intelligent enough to store
> stuff like that. Anyone?

After reading this over and over, I think this is what happened:

You unmounted your 9gig and, without shutting down, put in the 72gb drive.

The partition table and the divvy info were (quite naturally) in cache, 
so when you ran "mkdev hd", the 9 GB data was picked up and then written 
to the new disk at your request.  You then rebooted, but of course that 
was too late.

I suppose the controller cache could have added to this also- I don't 
know if it is smart enough to flush when a drive is replaced.

Morale: hot swap should ONLY be used for RAID systems.  For non-raid, 
shut the darn thing off when replacing drives.

-- 

Please note new phone number: (781) 784-7547

Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/1721.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here