Date: Sat, 17 Aug 2002 11:00:08 -0700 (PDT) From: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/20633: fdisk doesn't handle LBA correctly Message-ID: <200208171800.g7HI08Di037103@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: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
To: Bruce Evans <bde@zeta.org.au>, freebsd-gnats-submit@freebsd.org
Cc: freebsd-hackers@freebsd.org
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Sat, 17 Aug 2002 21:56:24 +0400
On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans 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.
Ok, so we must add option to fdisk(8) to print CHS?
And, BTW, does CHS makes sense inside an extended slices?
>>> 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.
Maybe we should take as magic cyls >1021? And where can one read all
this conventions?
>> 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
[skip]
>> 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
[skip]
>> 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
Looks like there is no adjustment for CHS, while there are wierd
adjustment requirements for LBA
>> 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
[skip]
>> 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
>> 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 :-).
and how translates that value to CHS? Guess 1023/255/63?
>
>> 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.
Any url? Or `google knows'? ;-)
I suppose, that it will be better to follow the linux' fdisk..
Could you please look at http://memphis.mephi.ru/~timon/fdisk/ (and http://memphis.mephi.ru/~timon at all ;-) since you'll need a patch from there or manually define DOSPTYP_EXTX if you'll try to compile it )?
And, one more : I suggest this discussion should go to -hackers...
(Adding a CC there...)
Sinceherely yours, Artem 'Zazoobr' Ignatjev.
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?200208171800.g7HI08Di037103>