Re: Installer: no option to set geometry/corrupts partition table

[randux@xxxxxxxxxxx]

Matthew Dillon wrote:
> :Hi Matt,
> :
> :There needs to be an option such as FreeBSD (and NetBSD and iirc 
> :OpenBSD) are providing, to set c/h/s for use by the DFly installer. I 
> :don't understand the comment that nobody is using it- all the *BSD show 
> :their view of it and if it doesn't match the partition table (which is 
> :laid out to this day in terms of c/h/s whether it's actual or virtual) 
> :it causes problems.
> :
> :For example, my machines are set up with 255 heads 63 sectors and how 
> :ever many cylinders the drive maps to.  I fdisk the drive and I create 
> :my partitions aligned on cylinder boundaries. When DFly installs it uses 
> :16 heads and some other factor for sectors. He changed the units on the 
> :partition table and this means that the partitions I had created before 
> :and after (locations, not times) the DFly target slice are no longer on 
> :integral boundaries, and that writing on the DFly filesystems can leak 
> :into my other partitions and corrupt data.
> :
> :There should be a simple way to set the c/h/s in the installer. 
> :Otherwise it does not play nice in a multiboot scenario.
> :
> :Cheers,
> :Rand
>
>     Well, my understanding is that tha partition table (the DOS parition
>     table) stores linear block values in addition to CHS values.  If you
>     tell the BIOS that the disk is in LBS or LARGE mode, the BIOS should 
>     use the linear block values.  CHS values are undependable no matter what
>     you do.  There is simply no proper way to set them that works with
>     all BIOSes.
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>
This BIOS doesn't seem to have any options, and at any rate I'm already 
running 7 other OS on the box without problems until now. The drives are 
much larger than the old limits so the BIOS and other kernels are 
clearly using large drive mappings sucessfully here.

The c/h/s values can be undependable in the abstract; they just have to 
work with the one BIOS that the partition table is used by. If I have x 
bytes to map and I arbitrarily decide that I'll call a cylinder 8225280 
bytes, and that there are 255 tracks in a cylinder, and 63 sectors in a 
track, then those c/h/s values tell me exactly where I am on the drive. 
LBA is just another way to express the same mapping. It doesn't matter 
what c/h/s I use as long as everybody who references the drive uses the 
same values.

Rand