Date: Sat, 17 Aug 2002 09:10:04 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/20633: fdisk doesn't handle LBA correctly Message-ID: <200208171610.g7HGA41v008648@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/20633; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Sun, 18 Aug 2002 02:12:45 +1000 (EST)
On Fri, 16 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
> On Sat, Aug 17, 2002 at 03:56:57AM +1000, Bruce Evans wrote:
> > On Fri, 16 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
> > > Hi, if I understand what jhb said in audit trail, following patch
> > > should solve the issue. Stephen, if it still bothers you, could you try
> > > it?
> > >
> > > --- sbin/i386/fdisk/fdisk.c Fri Aug 16 16:24:27 2002
> > > +++ sbin/i386/fdisk/fdisk.c Fri Aug 16 16:33:28 2002
> > > @@ -468,13 +468,21 @@
> [skip]
> > > - printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n"
> [skip]
> > > + /*
> > > + * if C/H/S of start or end are all set to 0xff, then C/H/S don't have
> > > + * enough bits to hold the address, and one should use LBA instead.
> > > + */
> > > + if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff ||
> > > + partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff ||
> > > + partp->dp_esect != 0xff || partp->dp_ehd != 0xff))
> > > + printf("\tbeg: cyl %d/ head %d/ sector %d;\n"
> [skip]
> >
> > Fdisk should print these values, at least optionally, since they are needed
> > for debugging. The magic values might be non-magic on old systems.
> Debugging WHAT? And, I can hardly imagine such a situation inside hard
> drives & slice tables.
Debugging hard disk tables and slice tables. I do it routinely. It
can be important to look at the raw data, but the dp_scyl...dp_ehd
data is a little too raw.
> > Also, the usual magic number of cylinders seems to be 1022, not 1023.
> I disagree. Now i'm hacking fdisk to work with extended slices, it can
We don't get to decide. There are braindamaged conventions about this
to give compatibility with broken BIOSes and broken fdisks.
Actually, 1023 is most magic (it is what the kernel expects), but the
data in the PR shows that 1022 is magic too. The magic 0xfe in the
kernel is for the ending head number. It can be important not to use
a starting or ending head number of 255 (== a head count of 256) because
some broken BIOSes crash on it, and there are now conventions that
prohibit using it.
> Take a look at the dump (I've cut all entries regarding extendeds below
> the top-level slicetable, since them all take space, but are of no
> interest now)
>
> Script started on Fri Aug 16 22:23:06 2002
> ******* Working on device /dev/ad4 *******
> parameters extracted from in-core disklabel are:
> cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
>
> Figures below won't work with BIOS for partitions not in cyl 1
> parameters to be used for BIOS calculations are:
> cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
>
> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 6 (Primary 'big' DOS (> 32MB)),
> start 63, size 2088387 (1019 Meg), flag 0
> beg: cyl 0/ head 1/ sector 1;
> end: cyl 129/ head 254/ sector 63
> The data for partition 2 is:
> sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
> start 2088450, size 8385930 (4094 Meg), flag 80 (active)
> beg: cyl 130/ head 0/ sector 1;
> end: cyl 651/ head 254/ sector 63
> The data for partition 3 is:
> sysid 131 (Linux filesystem),
> start 10474380, size 4192965 (2047 Meg), flag 0
> beg: cyl 652/ head 0/ sector 1;
> end: cyl 912/ head 254/ sector 63
> The data for partition 4 is:
> sysid 15 (Extended DOS, LBA),
> start 14667345, size 105435855 (51482 Meg), flag 0
> beg: cyl 913/ head 0/ sector 1;
> end: cyl 1023/ head 254/ sector 63
> The data for partition 5 is:
> sysid 130 (Linux swap or Solaris x86),
> start 14667408, size 256977 (125 Meg), flag 0
> beg: cyl 913/ head 1/ sector 1;
> end: cyl 928/ head 254/ sector 63
> The data for partition 7 is:
> sysid 131 (Linux filesystem),
> start 14924448, size 16771797 (8189 Meg), flag 0
> beg: cyl 929/ head 1/ sector 1;
> end: cyl 1023/ head 254/ sector 63
> The data for partition 9 is:
> sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
> start 31696308, size 40965687 (20002 Meg), flag 0
> beg: cyl 1023/ head 1/ sector 1;
> end: cyl 1023/ head 254/ sector 63
> The data for partition 11 is:
> sysid 12 (FAT-32, LBA),
> start 72662058, size 7389837 (3608 Meg), flag 0
> beg: cyl 1023/ head 1/ sector 1;
> end: cyl 1023/ head 254/ sector 63
> The data for partition 13 is:
> sysid 165 (FreeBSD/NetBSD/386BSD),
> start 80051958, size 8401932 (4102 Meg), flag 0
> beg: cyl 1023/ head 254/ sector 63;
> end: cyl 1023/ head 254/ sector 63
> The data for partition 15 is:
> sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
> start 88453953, size 25398702 (12401 Meg), flag 0
> beg: cyl 1023/ head 1/ sector 1;
> end: cyl 1023/ head 254/ sector 63
> Script done on Fri Aug 16 22:23:06 2002
Seems reasonable. It shows all of the magic beg and end values, because
the most magic one (all 0xff's) is so magic that it is never used :-).
> A-ha! Better see once, than hear many times: magic value for start is
> 1023/1/1, and for end is 1023/254/63, but note my FreeBSD slice - it was
> created using linux fdisk, but even these strange values works ok.
Linux fdisk apparently hasn't been dumbed down to follow current
conventions. It still uses a second-or third-best convention for the
"beg" values. These values should be as non-physical as possible so
that they don't get used by old BIOSes and are seen to be conventional
by most fdisks. The best values are probably 1023/255/63 for "beg"
and 1023/actual_heads/actual_sectors for "end".
> > Writing the correct magic numbers is more interesting. fdisk(8) doesn't
> > support it directly. You may have to change the C/H/S values to the magic
> > ones manually.
> Is there any papers on the subject? All my knowledge was obtained experimentally, watching how my dad revives dead hds....
> It looks like the magic is cyl=1023, regardless of h/s values...
I haven't kept up with the current conventions except for following the
changes in the FreeBSD boot loader and MBR-reading code to keep down^Wup
with them. Search the web. 10 year ago, one of the best documents was
by Hale Landis. I searched for "hale landis mbr" and found something
saying that "Hale no longer attempts to keep up with all the silly
and stupid things that OS designers are doing in partition tables" :-).
It still says that there are no standards. There is a new standard
named something like EFI GPT.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208171610.g7HGA41v008648>