Adding 60GB HDD to Netware 3.11 - is it possible?
Billy Ko
a legacy system, and 3.11 works just fine for what I need it for.
I'm using the ide.dsk mentioned in TID138, and already have a 12GB drive
installed.
Thanks,
Bill
Dave Lunn
past 32 gig IMO, and I would strongly advise you not to try on 3.11. You
need to upgrade to at least 3.12 or better yet 4.1x or later and use
IDEATA.HAM drivers.
--
Dave Lunn
NSCV Sysop
http://support.novell.com
Barry Schnur
This is 3.11 -- so this old note still applies:
First of all SCSI is the way to go for numerous reasons: ATA-2 (real name for
what are commonly called IDE or EIDE drives) are generally not as well made,
cannot multitask, if the master fails -- the slave will also, use more CPU
time (unless busmastering is enabled) and are not as quick (read RPM speed) as
their SCSI conterparts. But . . .
Seagate is completely wrong. You always want to use the version 3.xx IDE.DSK
or the IDEATA.HAM files.
First of all let me explain what LBA is. LBA is a different way of talking to
ATA-2 disks which makes much more logical sense. Like SCSI, all the computer
does is send the logical sector number instead of a C(yl)H(ead)S(ect) number
which was the previous method. The CHS number was an old system which has had
*absolutely* *no* resemblence to the location of the sector for some time now
(since all modern HDs pack many more sectors on the outer edges than they do
on the inner edges) and I am fairly certain that their are no HDs that
actually have eight platters (ie that 16 heads that you always type in).
Enabling LBA actually frees up a slight bit of CPU time when running on OS's
(Linux, OS/2, NT are some) that natively think in sector numbers, since they
no longer have to come up with the CHS number. Unfortunately, DOS (and by
extension Windows) is based upon the CHS method, so even if LBA is enabled,
DOS will still talk to the BIOS in CHS numbers which the BIOS will then
translate into LBA numbers to talk to the disk in (in other words -- in DOS,
it actually uses more CPU).
One problem is that most new BIOSes will not enable CHS translating *unless*
LBA mode is on (leading to the incorrect assumption that LBA is what breaks
the 504 meg barrier). Without CHS translating, the biggest ATA HD that DOS
can see is 1024 cyl *16 heads * 63 cyls * 512 bytes/sec= 504MB. CHS
translating just shifts the least significant bits in DOS cyl to the MSB of
heads. This means for a 2010 cyl 16 head reported ATA disk, DOS will see a
1005 cyl, 32 head disk. This gives a theoretical maximum DOS ATA drive of
1024 cyl *256 head * 63 sect * 512 = ~8GB. For drives bigger than this, DOS
will require a device driver that talks only in LBA mode. BTW, the maximum
theoretical size of an ATA drive is about 128GB.
Now -- how does LBA apply to Netware. Well since the IDE drives have never
been a recommended solution for Novell (for good reasons, IMHO), the IDE.DSK
and IDEATA.HAM drivers only talk to Netware in CHS format. Theoretically,
this shouldn't effect your HD's operation except run it a bit slower than
optimally. One small problem is that the IDE.DSK *before* verison 3.0, used
to ask DOS what the parameters of the drive were. If translating was enabled
(needed for >504 MB drives), then it would get the wrong parameters (ATA disks
can't report or use more than 16 heads) causing it not to function. IDE.DSK v
3.x and IDEATA.HAM both get the CHS parameters directly from the drive by
issuing a CP command to it and they work fine.
Enabling LBA (from my own testing) generally will not matter, *unless* you
have a brain bead controller or an Award BIOS between 7/29/94 (first version
with LBA support) and 12/31/94 (when they corrected it). These BIOSes and
some controllers for some unknown reason use a different disk layout when
communicating in CHS or LBA mode. Netware always talks in CHS mode, so if DOS
(read the BIOS) is using LBA mode, then your disk has a good chance of being
hosed next time you write to it using DOS (like installing PATCHES). Newer
machines should not have this problem. Notice that this problem was not
limited to Netware, a drive formatted with LBA enabled on one of these
computers will *not* work on any properly implemented LBA computer, either.
Bottom line is that since it is rare to have a need for a DOS partition of
504MB on a Netware Server, it is really no big deal to turn off the LBA in
BIOS and be better safe than sorry. Much like Barry's directions say to.
Barry Schnur
Novell Support Connection Sysop
Please post replies ONLY via the Newsgroup
Billy Ko
it's just so much more user friendly than IDE drives. But, this is the
legacy I need to live with. Maybe it's time to move on, like you said.
Bill
On Tue, 23 Jul 2002 21:12:03 GMT, Barry Schnur wrote:
:>>Sorry for all these questions about 3.11, but I'm trying to maintain/upgrade
Barry Schnur
>it's just so much more user friendly than IDE drives. But, this is the
>legacy I need to live with. Maybe it's time to move on, like you said.
>
I understand that it is a legacy environment, but why do you need a 60G drive?
Sounds like newer applications and larger storage requirements to me -- as in,
it is no longer really legacy.
Dave Lunn
What Barry and I are referring to is that you can run into address wrap
problems with IDE.DSK drivers and you won't see it coming. DO NOT use them
with a drive <8.4 gig. You might get away with it, but you won't get a
warning if you are not going to get away with it, and it might well take the
whole system down.
Billy Ko
current setup, and I am lucky I haven't fallen through yet, and that I still
might with no warning at all?
On Wed, 24 Jul 2002 14:39:29 GMT, Dave Lunn wrote:
:>Billy,
:>
:>
Barry Schnur
>current setup, and I am lucky I haven't fallen through yet, and that I still
>might with no warning at all?
>
Subject IDE with 3.12
From: Tom Ruby 74774,1440
The IDE drive is designed to be a DOS drive, and get around some silly
limitations in DOS. One of the main ones is the 10 bit cylinder field used
when DOS calls the BIOS to do disk I/O. Now, it's hard to make a big drive
with less than 1024 cylinders. So what the IDE drive does is have you tell
the BIOS (in type 47) that you've got say 54 sectors on the track. This is
actually lots more sectors than they can fit on a track, but what the IDE
drive does is interpret a couple bits of the sector address as part of the
cylinder address. Some drives may instead use a bigger than real head count.
Now, the ISADSK driver doesn't know how to interpret the type 47 spec since
there's little uniformity between BIOS's on how or where these specs are
stored. Netware doesn't use the BIOS to disk I/O because it can't afford to
have the processor tied up while the head is moving and it's waiting for the
desired sector to reach the head, so it's no help for the bios to know how to
find the specs.
In order to make IDE drives work, somebody at Novell created IDE.DSK. This
works because the designers of the IDE convention (which leaves lots to
interpretation) made an additional set of commands which use the physical
organization of the disk. One of them is "find out what the real cylinder,
sector and head figures are." IDE.DSK uses is command to find out how the
drive is organized, and the physical commands to read and write data.
Now, comes the hitch...
If you've specified x cylinders for the dos partition, Netware will indeed
leave x cylinders alone. Unfortunately, DOS is using x 54 sector cylinders,
while netware is leaving x 17 sector cylinders for DOS. Where do you think
those extra x * 37 sectors are? SOMEWHERE IN THE NETWARE PARTITION! Exactly
where is completely up to the designer of the drive in how he (or she)
implemented the translation scheme, and may vary from drive to drive.
So what do you do...
The safest thing to do is leave the DOS partition off. A lot of times, people
will get away with it because the DOS partition of a file server is frequently
nearly empty and they haven't stored DOS stuff in the shared area. If you've
got one, and a little bit of programming knowledge, you can test to see if
it's likely to work Ok (though, alas, even this isn't guaranteed).
Make yourself a simple program which writes a recognizable pattern into a file
until it runs out of space. Something like sequentiality numbered 32 bit
fields should do. When it gets an out of space error, close the file. Now,
make another program which reads through a file looking for this pattern.
Most any programming tool will be up to this task.
Now, down the server, and run the write program in the DOS partition. If you
really want to be safe, back the partition up and run it in as empty a DOS
partition as you can get away with. Now, bring the server up and run the
write program from a workstation to fill up the netware partition. Down the
server, and run the read program in the DOS partition. Did it pass? So far
so good. Erase the fill file, and run the write program again. Now, bring
the server up and run the read program from a workstation on the netware
partition. Still Ok? The odds are, it will work for you. Strangely, I've
seen this test pass on a 1 GIG IDE drive in one computer, and fail on the same
drive and adapter moved to a different computer. I didn't do much more
testing 'cause I'd already wasted a week or so and needed the computers for
other purposes.
Now the EIDE drive is designed to get around yet another silly DOS limitation
and allow you to have a gigabyte drive for DOS. My computer at home has a 1
gig drive and will report 1200 meg using chkdsk. Unfortunately, it introduces
a whole bunch more things which may differ from drive to drive or controller
to
controller, or even BIOS to BIOS, so you're probably not ever going to see a
generic EIDE.DSK driver. As I understand, a couple controller manufacturers
have produced .DSK drivers for their controllers, but these are married to
specific controllers. If you MUST use IDE, get one of these and follow the
manufacturer's suggestions religiously. My computer at home will run 4 of
these EIDE drives using a specialized BIOS and built in adapter. Use it as a
file server? Fat chance! Nice workstation though.
But then, why bother with the whole issue? SCSI drives cost roughly the same,
well, within a few hundred for the whole server. Ok, you'll not find them in
the "special of the week" sheet from Computer Playground. In fact, there are
SCSI and IDE drives which differ ONLY in the circuit board on the bottom of
the drive, and silicon's cheap. The SCSI drive has better performance. Yes,
I know the EIDE drives are faster than the IDE drives, but still about 1/2
what average SCSI drives are doing these days. Also, SCSI drives can be given
a set of commands to do, and will do them while netware deals with other
drives. Netware makes good use of this. SCSI allows you to hang 7 drives off
a single host adapter, and you can put as many host adapters as you can find
ports and interrupts for (except in some PCI computers).
Tom Ruby
************************************************************************
Dave Lunn
When you find out you have a problem is when address wrap overwrites
something you try to use. That would be bad enough, but you often wont be
able to discover it in the first day or so, so it might overwrite a lot of
stuff until it kills something that the system needs to function.
Billy Ko
Today I learned something that scared me. I found out that the way the 12GB
partition was made was by creating a partition through a 3rd party software
(they can't remember what - thanks a lot), then booting the server, then
using install.nlm to kill the new partition and make a NetWare partition.
(Or at least something to that effect.)
From reading all the info, I am gathering that the IDE driver defaulted to
querying the partition table info to configure itself!
Isn't that like a "last resort" thing for the IDE.DSK?
Bill