Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jun 2009 12:51:27 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Ulf Lilleengen <lulf@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r194333 - head/sbin/fdisk
Message-ID:  <20090618104415.H27191@delplex.bde.org>
In-Reply-To: <200906170641.n5H6fAXa064961@svn.freebsd.org>
References:  <200906170641.n5H6fAXa064961@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jun 2009, Ulf Lilleengen wrote:

> Log:
>  - Back out the previous change in order to maintain compatibility.

Thanks.

This even maintains compatibility with fdisk's own man page, since you
didn't change that to say 255 instead of 256.

I'm not sure about the corresponding change in sysinstall^Wlibdisk.
Wizard mode is needed to check what is happening, but is not the
default.

Linux cfdisk (a 2005 version) doesn't permit 256 heads, at least when
the number of heads is specificed on the command line.  Its man page
is missing documentation of the limits -- it only says that 255 and
16 are reasonable values for the number.

Linux fdisk has the same man page as Linux cfdisk.  It allows 256 heads
at least in 'x' interactive mode and documents the limits of 1-256
heads in the prompt for changing the number there.  It also allows
specifying 257 or even a completly garbage number of heads (> 2**^64)
on the command line, but when the number exceeds 255 it silently changes
it to 255.  So Linux [c]fdisk apparently allows 256 heads iff it is
set in interactive mode.

There is another dubious 255 in fdisk.c, together with mounds of other
bugs:

% static void
% print_params()
% {
% 	printf("parameters extracted from in-core disklabel are:\n");
% 	printf("cylinders=%d heads=%d sectors/track=%d (%d blks/cyl)\n\n"
% 			,cyls,heads,sectors,cylsecs);
% 	if((dos_sectors > 63) || (dos_cyls > 1023) || (dos_heads > 255))
% 		printf("Figures below won't work with BIOS for partitions not in cyl 1\n");
% 	printf("parameters to be used for BIOS calculations are:\n");
% 	printf("cylinders=%d heads=%d sectors/track=%d (%d blks/cyl)\n\n"
% 		,dos_cyls,dos_heads,dos_sectors,dos_cylsecs);
% }

This function is mostly wrong:
- The values are now _never_ extracted from the in-core disklabel.
   They are normally wrong ones extracted from the firmware.  The
   firmware ones are logically wrong in this context and are usually
   practically wrong too (except for sectors = 63 and cyls = irrelevant).

   The values used to be normally extracted from the (in-core = virtual)
   disklabel, and the ones there used to be extracted from existing
   entries in the partition table, mainly so as to get correct values
   here and in other implementations of fdisk (so as to centralize the
   code), but this has been axed.

- all disks larger than 503MB have parameters that "won't work [...]".
   Thus the warning is printed for all disks less than about 15 years old,
   unless you type in bogus parameters to shut it up.  (You can type in a
   bogus number of cylinders without affecting much.)  It will still be
   printed initially.

- dos_sectors > 63 causes problems beginning at cyl 0 head 1, not for cyls
   != 1 as stated
- dos_cyls > 1023 causes problems beginning at cyl 1024, not for cyls != 1
   as stated
- dos_heads = 256 shouldn't cause any problems.  It may, but not the ones
   stated.
- dos_heads > 256 causes problems beginning at cyl 1, not for cyls != 1 as
   stated (cylinders are based at 0, so cyl 1 should mean the second cylinder).

- "Figures" that are stated not to work may work, and probably mostly do now,
   since the CHS values in partition tables aren't really needed.
   dos_cyls > 1023 has been mostly working for about 15 years now, ever since
   exceeding it became the usual case.  This used to be handled by requiring
   conventional garbage instead of the unrepresentable values >= 1024, and/or
   by never actually using the CHS values when they are inconsistent with
   the LBA values.  The latter method should work for all garbage CHS values.
   FreeBSD fdisk might have been responsible for creating many garbage CHS
   values, by supplying bad "firmware" defaults which the user accepts.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090618104415.H27191>