divvy / NON FS / filesystem problem

divvy / NON FS / filesystem problem

Post by Andrzej Kowals » Fri, 28 Mar 1997 04:00:00



I am building a new server and moved 4 existing SCSI  hard drives from
a  SCO 5 server running an Adaptec VESA bus controller to a new
Pentium PRO machine with an Adaptec 2940UW controller.

I managed to installt 3 out of 4 hard drives preserving their data.
The 4th problematic hard drive is a 1 GB IBM drive and the problem is
that divvy reports the filesystem type as NON FS.  This is the divvy
table:

+-------------------+------------+--------+---+-------------+------------+
| Name              | Type       | New FS | # | First Block | Last Block |
+-------------------+------------+--------+---+-------------+------------+
| local2            | NON FS     |  no    | 0 |            0|     1056767|
|                   | NOT USED   |  no    | 1 |            -|           -|
|                   | NOT USED   |  no    | 2 |            -|           -|
|                   | NOT USED   |  no    | 3 |            -|           -|
|                   | NOT USED   |  no    | 4 |            -|           -|
|                   | NOT USED   |  no    | 5 |            -|           -|
|                   | NOT USED   |  no    | 6 |            -|           -|
| hd3a              | WHOLE DISK |  no    | 7 |            0|     1057775|
+-------------------+------------+--------+---+-------------+------------+

You see that local2 is designated as NON FS.  It should be HTFS as it
was on the former server.  I did not delete or create a new division.
I can't mount it or run fsck on it becase the OS can't stat the
filesystem type.

Q: how can I change the filesystem type to HTFS and preserve the data
(assume no backup).?

Q: Is there another way to make the drive accessible or possibly to
copy the data off it onto a new drive?

My ISP has flaky newservice so I would appreciate an email copy of any
posted response.

Andrzej Kowalski
################
Andrzej Kowalski
KE Software Inc.

http://www.kesoftware.com  
303-601 West Broadway
Vancouver, BC, Canada, V5Z 4C2
Tel: (604) 877-1960 ext. 12
Fax: (604) 877-1961
###############

 
 
 

divvy / NON FS / filesystem problem

Post by Bela Lubki » Sun, 30 Mar 1997 04:00:00



> I am building a new server and moved 4 existing SCSI  hard drives from
> a  SCO 5 server running an Adaptec VESA bus controller to a new
> Pentium PRO machine with an Adaptec 2940UW controller.

> I managed to installt 3 out of 4 hard drives preserving their data.
> The 4th problematic hard drive is a 1 GB IBM drive and the problem is
> that divvy reports the filesystem type as NON FS.  This is the divvy
> table:

> +-------------------+------------+--------+---+-------------+------------+
> | Name              | Type       | New FS | # | First Block | Last Block |
> +-------------------+------------+--------+---+-------------+------------+
> | local2            | NON FS     |  no    | 0 |            0|     1056767|
> |                   | NOT USED   |  no    | 1 |            -|           -|
> |                   | NOT USED   |  no    | 2 |            -|           -|
> |                   | NOT USED   |  no    | 3 |            -|           -|
> |                   | NOT USED   |  no    | 4 |            -|           -|
> |                   | NOT USED   |  no    | 5 |            -|           -|
> |                   | NOT USED   |  no    | 6 |            -|           -|
> | hd3a              | WHOLE DISK |  no    | 7 |            0|     1057775|
> +-------------------+------------+--------+---+-------------+------------+

> You see that local2 is designated as NON FS.  It should be HTFS as it
> was on the former server.  I did not delete or create a new division.
> I can't mount it or run fsck on it becase the OS can't stat the
> filesystem type.

> Q: how can I change the filesystem type to HTFS and preserve the data
> (assume no backup).?

You cannot.  The problem is not with the filesystem's type, but with the
disk geometry.  What divvy displays as "type" is actually divvy's
interpretation of what the data inside looks like.  When you expect a
filesystem to have one type and divvy comes up with another, it's
because divvy is probably looking at the wrong area of the disk.

Divisions are relative to a partition.  Partitions are relative to a
disk.  The fact that divvy found a division table at all indicates that
the offset of the start of the partition from the start of the disk is
correct.  This suggests that the number of sectors/track is correct, and
that the partition starts near the start of the disk.  The fact that
divvy finds wrong data inside the divisions shows that some other
geometry parameters are wrong.

Quote:> Q: Is there another way to make the drive accessible or possibly to
> copy the data off it onto a new drive?

Yes.  Make the geometry correct.

If one of the other three drives used to be the root drive, look in its
/usr/adm/messages.  Find the old geometry used for this drive ("%Sdsk
... cyls=... hds=... secs=...").  Stamp that geometry onto the drive as
follows:

  # dparam /dev/rhd30 cyls hds 0 0 0 0 0 secs
                               \_______/
                               FIVE ZEROS

I believe you must then reboot before the drive can be accessed
correctly.

A guess: the other three drives were slightly less than 1GB?  Whereas
this one is slightly more than 1GB.  The old adapter probably used a
geometry of 64 heads, 32 sectors/track, and enough cylinders to multiply
out to the capacity; this drive's old geometry was probably something
like 1038 cylinders, 64 heads, 32 sectors.  The new adapter probably
changes geometries at 1GB, in order to stay below 1024 cylinders;
perhaps it is using 519 cylinders, 128 heads, 32 sectors.  The other
three drives are working because both adapters agree how to map drives
<1GB.

You could probably also fix this by going into BIOS setup for the 2940
(^A during BIOS startup).  There will be a parameter like "extended
translation for >1GB drives" or something like that.  Toggle that and
see what happens.

Once all drives are accessible, I recommend stamping each of them with
their parameters.  They will then retain those parameters even when
moved to a different host adapter with a different geometry.  For each
drive:

  # dparam /dev/rhdX0 `dparam /dev/rhdX0`

I consider it a bug that we don't automatically do that on SCSI drives.

The command works by reading out the *kernel*'s idea of the geometry and
actually physically stamping it onto the *disk* in a location understood
by the SCO Unix boot programs.  It only looks like a no-op.  It actually
promotes onto the physical medium information which is normally derived
from a complex chain of events played out between the disk, host
adapter, host adapter BIOS, system BIOS, and SCO boot programs.  A
change in any of those components can disturb the final resulting
geometry understood by the kernel.  It's much safer to just save it away
the first time, and forever thereafter use the same values.

- Show quoted text -

Quote:>Bela<


 
 
 

divvy / NON FS / filesystem problem

Post by Jean-Pierre Radle » Sun, 30 Mar 1997 04:00:00


Bela Lubkin telecommunicated:
| Once all drives are accessible, I recommend stamping each of them with
| their parameters.  They will then retain those parameters even when
| moved to a different host adapter with a different geometry.  For each
| drive:
|
|   # dparam /dev/rhdX0 `dparam /dev/rhdX0`
|
| I consider it a bug that we don't automatically do that on SCSI drives.
|
| The command works by reading out the *kernel*'s idea of the geometry and
| actually physically stamping it onto the *disk* in a location understood
| by the SCO Unix boot programs.  It only looks like a no-op.  It actually
| promotes onto the physical medium information which is normally derived
| from a complex chain of events played out between the disk, host
| adapter, host adapter BIOS, system BIOS, and SCO boot programs.  A
| change in any of those components can disturb the final resulting
| geometry understood by the kernel.  It's much safer to just save it away
| the first time, and forever thereafter use the same values.

Which begs the question:

Why should the kernel have * knowledge of a disk's geometry?

So long as the kernel knows the total number, T, of blocks on a hard drive,
isn't it possible for the kernel to ask for a read/write of some block B
( 0 <= B <= T ) and let the host_adaptor/hardware do the nitty-gritty work
of discovering that B is on sector S, head H, cylinder C?

--

 
 
 

divvy / NON FS / filesystem problem

Post by Bela Lubki » Sun, 30 Mar 1997 04:00:00



> Bela Lubkin telecommunicated:
> | The command works by reading out the *kernel*'s idea of the geometry and
> | actually physically stamping it onto the *disk* in a location understood
> | by the SCO Unix boot programs.  It only looks like a no-op.  It actually
> | promotes onto the physical medium information which is normally derived
> | from a complex chain of events played out between the disk, host
> | adapter, host adapter BIOS, system BIOS, and SCO boot programs.  A
> | change in any of those components can disturb the final resulting
> | geometry understood by the kernel.  It's much safer to just save it away
> | the first time, and forever thereafter use the same values.

> Which begs the question:

> Why should the kernel have * knowledge of a disk's geometry?

> So long as the kernel knows the total number, T, of blocks on a hard drive,
> isn't it possible for the kernel to ask for a read/write of some block B
> ( 0 <= B <= T ) and let the host_adaptor/hardware do the nitty-gritty work
> of discovering that B is on sector S, head H, cylinder C?

Especially on a SCSI drive, the kernel does very little with the
geometry.  Mainly, it's used in calculations of boundaries.  Most
importantly, the reserved area of a partition consists of the (unused)
boot sector, the divvy table, the alias track/sector table, the alias
tracks/sectors, and then unused padding up to the next cylinder
boundary.  Changing geometries makes the divisions un-findable precisely
because it changes the cylinder boundaries.  It would be nice to change
this, except that doing so would render existing Unix partitions
inaccessible...

- Show quoted text -

Quote:>Bela<