> Frantisek Holop wrote: > > > > i am reading the fdisk source to have a better understanding > > what is what... it is not going really well i am afraid :]
Please read up on hale landis' "how it works" series. It's roughly the best I've found on the subject. http://www.ata-atapi.com/hiwmbr.html Once you're understood that, then we can discuss more of what is going on. > > first of all, i had a long hard look at the basic programs > > that give information about disks in general: fdisk, disklabel, > > and atactl (obviously, only for ata disks) and /boot. > > > > both fdisk and disklabel use the DIOCGDINFO ioctl to get the > > disk geometry (and other info) but atactl is using the WDCC_IDENTIFY > > ata command while /boot is using int 13h. consider the following > > output from my eeepc: > > > > $ sudo fdisk wd0 > > Disk: wd0 geometry: 486/255/63 [7815024 Sectors] > > <snip> > > > > $ sudo disklabel wd0 > > <snip> > > sectors/track: 63 > > tracks/cylinder: 255 > > sectors/cylinder: 16065 > > cylinders: 486 > > total sectors: 7815024 > > <snip> > > > > $ sudo atactl wd0 > > <snip> > > Cylinders: 7753, heads: 16, sec/track: 63, total sectors: 7815024 > > <snip> > > > > the boot output is not here, but it gave me the same numbers > > as fdisk. Yes, the boot output, and the fdisk output need to be the same for things to work. The rest is really not necessary to be the same, things will continue to work, as long as the LBA's match up. > > so atactl's different (sigh). but the thing is, that if i trace back > > what the DIOCGDINFO ioctl does in ata.c and wd.c, ... it is the same > > WDCC_IDENTIFY that atactl does... what am i missing here? Possibly when and how the result/geo is set? > > the other issue i have been pondering is, the user mode -chs in fdisk. > > i remember back then when i had this clash of geometries (between say > > partition magic, and openbsd) i was inclined to use the partion magic > > one... so i had a geometry i wanted to use to override the one openbsd > > was giving me. but even if i specified it with -chs, fdisk still used > > the one it found. now i see in the source, that the user given geometry > > is considered, but only if there is no geometry found by the system, if > > the system finds one, it simply overwrites the user defined values. > > is this intentional? if the user is brave enough to supply a geometry, > > shouldn't it be used over the detected one? You better read the code again. In particular, read the DISK_getmetrics() function. As far as I can tell, if user supplied metrics (geometry) is supplied, it's the one that is used. > > this would have been useful for me with dual boot when there is already > > some other system on the disk installed with using a different geometry. > > by entering this "custom" geometry, one will be able to use openbsd's > > fdisk with "proper" partition boundaries with a greater chance of not > > overwriting already existing partitions. > > > > if what i am saying is rubbish (more than possible) then at least i > > think this should be documented in the man page because basicly the user > > suplied -chs values are ignored if there is system geometry present... If the system gave you a geometry, that's the one you want to you. You can't just make up whatever geometry you want. This is not some sort of negotiable thing. If 'partition magic' used it's own, different geometry from what the bios was/is using, and it worked, it was a simple *ACCIDENT*. --Toby.
