Subject: Re: Help with >1024 cyl drive
To: John C. Hayward <johnh@david.wheaton.edu>
From: Bill Studenmund <skippy@macro.stanford.edu>
List: current-users
Date: 07/12/1995 10:37:05
On Wed, 12 Jul 1995, John C. Hayward wrote:

> Dear NetBSDers,
>    I am attempting to set up NetBSD on a i386 machine Packard Bell Pentium
> with a Gig drive. Both the CMOS and NetBSD when probing see the drive as: 
> 
> 2099 cyl, 16 heads and 63 sectors/track
> 
> However both PFDISK and FIPS12 report:
> 
> 522 cyl, 63 heads and 63 sectors/track  
> 
> My guess is that something is maping stuff in DOS to less than 1024
> cylinders.
> 
> This disk must be usable both by DOS and NetBSD and presently we have
> the disk partitioned for cylinders 300-522 (these are what DOS calls
> cylinders).
> 
> Since the total number of sectors is off my a fair margin do I tell 
> NetBSD to start at 63*63*300 (1190700) sector or do I assume the
> mapping which takes place results in each "dos" cylinder starting
> on an actual cylinder (at 4*300) 1200 cylinder (4 from ceiling of 
> 63/16)?

It's a SCSI drive? If not, is it on an interface where the cpu has to
tell the drive to seak to a track & read a sector, or just to read
a sector off the drive w/ no control from the host? If the host has
to tell it to step tracks, ignore what I'm about to write.

Off hand, I'd guess you should just go for the dos partition point. But
then I'm a mac user. :-) I actually didn't worry about cylinders when I
set up my partitions, and everything seems fine.

Actually, this discussion brings up a question I've had. Disk drives have
changed a lot since the first UNIX file systems. Nowadays, SCSI drives
have read & write caches which run independent of the host, and (more
important to this thread) can hide bad sectors & have a variable number
of sectors per track.

With all these changes, do we still need to stick hard to the idea
of cylinders? Sure, we can optimize head motion, but there is so much
that can go on in the drive, hidden from the host cpu, that we miss this
ideally optimized state we're shooting for. Is it worth the effort?

> Any pointers would be appreciated.
> 
> johnh...
>