NetBSD Problem Report #6624

Received: (qmail 15751 invoked from network); 21 Dec 1998 04:15:28 -0000
Message-Id: <m0zrwjl-0009LvC@most.weird.com>
Date: Sun, 20 Dec 1998 23:14:29 -0500 (EST)
From: woods@mail.weird.com
Reply-To: woods@mail.weird.com
To: gnats-bugs@gnats.netbsd.org
Subject: NetBSD (in particular "disklabel") should probably not use sectors/track and sectors/cyl. on SCSI disks...
X-Send-Pr-Version: 3.95

>Number:         6624
>Category:       bin
>Synopsis:       NetBSD (in particular "disklabel") should probably not use sectors/track and sectors/cyl. on SCSI disks...
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          suspended
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 20 20:20:01 +0000 1998
>Closed-Date:    
>Last-Modified:  Mon Apr 28 03:32:03 +0000 2008
>Originator:     Greg A. Woods
>Release:        NetBSD-current
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:

System: NetBSD

>Description:

	Modern disks, including almost any SCSI disk that still spins
	today, use constant density recording techniques that make the
	number of sectors per track.

	As a result many modern (SCSI) disks also totally hide the true
	geometry of the disk (usually behind a RAM buffer).  The actual
	sector sequence layout of the disk may be completely different
	than any driver could ever guess without knowing the on-board
	controller firmware intimately.

	Operating system software that still calculates disk
	partitioning and filesystem parameters based on recording
	surface count, sectors per track, cylinders per spindle,
	rotational speed, interleave, etc., is likely to be so
	incredibly wrong that disks with small cache buffers will likely
	be slower than if the OS simply ignored all of this faked up
	geometry information (though this is something I've yet to see
	proven).  Even if it's not all that much slower, the additional
	unnecessary complexity and confusion should be avoided for the
	user's sake.

>How-To-Repeat:

	Obverve that on some modern disks as much as 1-2 MB can be lost
	due to rounding errors:

	sd2: 4345MB, 6144 cyl, 8 head, 181 sec, 512 bytes/sect x 8899737 sectors

	8 heads * 181 avg.sect/trk = 1448 sect/cyl

	1448 sect/cyl * 6144 cyl = 8896512 sectors

	8899737 - 8896512 = 3225 lost sectors

	That's only 0.03% of the available disk space, but still!  ;-)

>Fix:

	Make disklabel smarter so that it ignores sectors/track on SCSI
	disks where such a measurement is meaningless (or "average" at
	best).  This might not be too difficult, assuming the user
	manages to put the right keyword into the "type" field to hint
	that the sectors/track value is an "average" value.

	Disklabel should also ignore cylinder boundary checks except on
	those architectures (sun3 + sparc) where it is known that the
	PROM refuses to boot from partitions that don't "jive".

	Make FFS ignore disk geometry on modern disks.  This is not so
	easy to do, unfortunately....
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: fair 
State-Changed-When: Wed Jun 16 02:18:53 PDT 1999 
State-Changed-Why:  
The C/H/S assumption is buried pretty deep in FFS. Without a redesign, 
we're stuck with it, unless you have rewritten FFS ... ? 

From: woods@most.weird.com (Greg A. Woods)
To: fair@netbsd.org
Cc: gnats-admin@netbsd.org
Subject: Re: bin/6624
Date: Wed, 16 Jun 1999 10:28:04 -0400 (EDT)

 [ On , June 16, 1999 at 09:19:58 (-0000), fair@netbsd.org wrote: ]
 > Subject: Re: bin/6624
 >
 > The C/H/S assumption is buried pretty deep in FFS. Without a redesign,
 > we're stuck with it, unless you have rewritten FFS ... ?

 Well, yes, though I'd argue that it's really in the implementation, not
 the overall design, but it amounts to the same thing:  a re-write.

 What I think I was thinking of in this particular case though is that it
 might be possible to always use a fixed geometry for SCSI and other
 formats where the physical addressing is always normally done by an
 offset, not by C/H/S.  After all most PCI and ISA controllers already do
 some kind of mapping like this to appease those dumb PC BIOSes.

 -- 
 							Greg A. Woods

 +1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
State-Changed-From-To: feedback->analyzed 
State-Changed-By: tv 
State-Changed-When: Mon Nov 13 10:17:54 PST 2000 
State-Changed-Why:  
Analyzed, but we don't know if this will ever happen. 
State-Changed-From-To: analyzed->suspended
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 28 Apr 2008 03:32:03 +0000
State-Changed-Why:
In these days of LBA48 and LBA64 all this stuff more or less works, but
ripping out the last vestiges of C/H/S addressing from places it does not
belong is a large undertaking with low return for effort. So I'm going to
mark this suspended, at least for the time being, unless someone wants to
step up and actively work on it.


>Unformatted:

Home	PR Database Search