Article View: comp.os.netware.misc
Article #661Re: File corruption on NetWare 3.12
From: Stephen M. Dunn
Date: Tue, 13 Jun 1995 00:00
Date: Tue, 13 Jun 1995 00:00
105 lines
6453 bytes
6453 bytes
In article <3r0ctb$2c6@news.primenet.com> hbae@Primenet.Com (Hansang Bae) writes:
$Arghh, the old intermittant problems. Enough to drive one insane. Out
$of curiosity, do you remember if parity was enabled on the SCSI disk
$farm (and the controller)?
Both, I believe.
In any case, I think we've found the culprit. The folks who installed
this system turned on the host adapter's translation option for drives
above 1 GB. I know from past experience that doing this on a 154xC
makes the NetWare drivers barf, and Adaptec tech support confirms that
this is a Bad Thing for the 294x as well.
The cure for this is fairly lengthy in terms of time, though
conceptually simple. Some background is perhaps in order, though,
to explain what this option does and when it's required. For those
who know this stuff already, you might as well skip to the next
message; the rest is pretty lengthy.
DOS uses BIOS services to read and write hard drives. This
interface basically came along with the IBM PC XT. In yet another
example of a standard being set that didn't stand the test of time,
IBM imposed some limitations on the numbers of cylinders, heads,
and sectors per track that they felt were necessary to represent
a hard drive. They specified how these values were to be
packed into registers for the appropriate BIOS calls, and in doing
so set limits on how large a hard drive could be supported through
BIOS calls. Since DOS generally uses BIOS calls, they indirectly
set the same limit on DOS. This is where the roughly 508 MB limit
on traditional IDE drives comes from, BTW.
SCSI hard drives, internally, are constructed just like any
other hard drives - they're a collection of heads and cylinders,
and there is some number of sectors on each track (through in
modern drives, this number may not be the same for every track).
However, this isn't how they present themselves to a system.
They simply appear as a long, linear string of sectors; it's up
to the drive's firmware to figure out where a given logical sector
is physically located.
The BIOS makes no provision for a hard drive which isn't composed
of cylinders, heads, and the same number of sectors per track, and
so in order for such a hard drive to be useful to an OS which expects
to make BIOS calls, the host adapter has to provide a fake geometry
for the hard drive. Traditionally, this has involved setting the
numbers of heads and sectors per track such that each cylinder has
one megabyte of storage. Once this has been done, BIOS calls appear
to work normally, and between the host adapter and the hard drive
everything is translated so that it works nicely.
One of the three limits IBM designed was on the number of cylinders.
They set the limit at 1024, by using ten bits to represent the cylinder
number. If a SCSI host adapter maps each logical cylinder to one
megabyte of storage, then it can't present more than one gigabyte
to an OS using BIOS calls. With the advent of SCSI hard drives with
over a gig of storage capacity, something had to change. This is where
the BIOS option in the 294x, 154xC, and many other host adapters
comes into play. It alters the number of heads and/or sectors per
track to make more than one megabyte correspond to each logical
cylinder (AFAIK, most of these translations map eight megs per
cylinder, moving the ceiling for BIOS calls up to 8 GB ... for now,
at least, very, very few DOS users would try anything close to this
size).
However, NetWare, Unix, and other OSes which run in protected
mode doesn't use real-mode BIOS calls. They use their own protected-mode
drivers for the specific host adapter. This is also done for other
reasons, as well; for example, the BIOS call doesn't return until
the operation has completed, negating SCSI's ability to handle
multiple simultaneous requests. Since this protected-mode driver
doesn't use the BIOS, it's immune to the BIOS limitations. This
makes the >1GB translation option unnecessary for such an OS.
Unfortunately, if the drive has been set up using one translation
and is then used with a driver which expects another translation,
you get problems. I don't know why drivers aren't written to check
what translation has been set and adapt to it, but it seems they
aren't. They're written with the assumption that you've not used
the unnecessary >1GB translation, and if you've turned this translation
on on your host adapter, well, oops.
So the moral of the story is that DOS needs this translation option
set if the drive's size exceeds 1 GB (that's 1 real gigabyte, not
the roughtly 5% smaller 1 Drive Manufacturer's Gigabyte) and doesn't
need it if the drive's size is under a gig. Real OSes, in general,
don't need this translation set, and usually require that it _not_
be set.
Now, for the cure. Back up the data and verify it carefully.
Make everything you'd normally make for an emergency preparation
kit - copies of STARTUP.NCF, AUTOEXEC.NCF, your NetWare diskettes,
everything on the DOS partition, backup software, etc. Now
turn off the >1GB translation, do a low-level format (Adaptec
says this is required; I've seen it work sometimes, but not always,
without this step, so it's prudent to do it), recreate the DOS
partition, reinstall NetWare, restore your backup.
Thanks to all who have made suggestions on how to approach this
problem. I'm pretty confident that this is the cure; if it isn't,
I'll let y'all know :-)
--
stephen@bokonon.UUCP ...!{xrtll,gts.org}!bokonon!stephen
----------------------------------------------------------------------------
Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7 (416) 750-7946 x251
Technical Details
Message-ID:
<DA3Bu9.LM@bokonon.UUCP>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<B3D21EBC0819@magic.hi.net> <D9o8wz.2FD@bokonon.UUCP> <3r0ctb$2c6@news.primenet.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fe659,551869cd2282a43f X-Google-Attributes: gidfe659,public X-Google-Thread: f8bf7,551869cd2282a43f X-Google-Attributes: gidf8bf7,public From: stephen@bokonon.UUCP (Stephen M. Dunn) Subject: Re: File corruption on NetWare 3.12 Date: 1995/06/13 Message-ID: <DA3Bu9.LM@bokonon.UUCP> X-Deja-AN: 104461632 references: <B3D21EBC0819@magic.hi.net> <D9o8wz.2FD@bokonon.UUCP> <3r0ctb$2c6@news.primenet.com> organization: United System Solutions Inc. newsgroups: comp.os.netware.misc,bit.listserv.novell