From owner-freebsd-bugs  Wed Mar 29 01:35:18 1995
Return-Path: bugs-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15153 for bugs-outgoing; Wed, 29 Mar 1995 01:35:18 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA14924; Wed, 29 Mar 1995 01:34:59 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA25301; Wed, 29 Mar 1995 19:33:09 +1000
Date: Wed, 29 Mar 1995 19:33:09 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503290933.TAA25301@godzilla.zeta.org.au>
To: bde@zeta.org.au, gvrooij@mmra1.ms.philips.nl
Subject: Re: kern/280: new slice manager totally confused about old slice disks
Cc: freebsd-bugs@freefall.cdrom.com, jkh@freefall.cdrom.com, pst@shockwave.com
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

>> I think sysinstall creates a valid disk label with size 
>> #secpertrack * #heads * #cyl in both the d_secperunit and the 'd' partition
>> size fields.  The problem occurs when the sd driver blows away the 'd'
>> partition size field (replacing it with the total #sec) without touching
>> the d_secperunit field.  The wd driver is more careful and verbose.  It

>Might well explain what we see indeed. But the same holds for the c partition.

Maybe sysinstall set the size of the c partition correctly to extend to
the end of the disk, and d_secperunit to match.  Old versions of
`disklabel -e' rounded down d_secperunit to a cylinder boundary so running
`disklabel -e' could cause the problem.

>But what abt the following scheme: 
>I've got a disk, labeled by 2.0R whit only one slice, namely for freebsd
>with the defect I mentioned earlier (i.e. that the sd driver replaces
>the c and d partition sizes with larger values than possible according
>to the other drive params.).
>I dont have sources handy and might well mix up the order of evaluation
>but if the slice code rejects the c and d partitions because of their
>sizes, it will also at least reject the (physically) last partition...

The c partition size is rounded down while the d partition is rejected.
These partitions are not used for normal operation (except maybe sector
#2 of partition c to read the label) so normal operation is not normally
affected.  Similar rounding down of the a partition (e.g.) would cause
problems if the file system extends into the lost sectors.  Most such
problems are avoided by specially handling the 50000-sector "whole
disk for FreeBSD" partition table.

Bruce