HDIO_GETGEO vs. BLKGETSIZE

HDIO_GETGEO vs. BLKGETSIZE

[David Woodhouse]

Is it permitted for a driver to returns CHS values for HDIO_GETGEO which, 
when multiplied together, don't match the value returned by BLKGETSIZE?

i.e. Is the code in the second 'if' statement below actually necessary?


        thisNFTL->cylinders = 1024;
        thisNFTL->heads = 16;

        temp = thisNFTL->cylinders * thisNFTL->heads;
        thisNFTL->sectors = thisNFTL->nr_sects / temp;

        if (thisNFTL->nr_sects % temp) {
                thisNFTL->sectors++;
                temp = thisNFTL->cylinders * thisNFTL->sectors;
                thisNFTL->heads = thisNFTL->nr_sects / temp;

                if (thisNFTL->nr_sects & temp) {
                        thisNFTL->heads++;
                        temp = thisNFTL->heads * thisNFTL->sectors;
                        thisNFTL->cylinders = thisNFTL->nr_sects / temp;
                }
        }
	/* Do we really need to do this.... ? */
        if (thisNFTL->nr_sects != thisNFTL->heads * thisNFTL->cylinders *
            thisNFTL->sectors) {
                printk("NFTL capacity reduced for geometry reasons from %lx to %x sectors\n", thisNFTL->nr_sects, 
                       thisNFTL->heads * thisNFTL->cylinders * thisNFTL->sectors);

                thisNFTL->nr_sects = thisNFTL->heads * thisNFTL->cylinders * thisNFTL->sectors;
        }


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[Andries Brouwer]

On Mon, May 22, 2000 at 01:06:17PM +0100, David Woodhouse wrote:

> Is it permitted for a driver to returns CHS values for HDIO_GETGEO which, 
> when multiplied together, don't match the value returned by BLKGETSIZE?

Yes - HDIO_GETGEO may contain whatever you want.
A modern fdisk will use the values for heads and sectors/track
given by HDIO_GETGEO, but ignore the value for cylinders.

Indeed, since cylinders is a 16-bit field and the number of cylinders
can be larger than 65535, the value may be truncated, and is to be
considered worthless.

Instead, the number of cylinders is computed as BLKGETSIZE/(H*S).
(Thus, there is no need for a new ioctl HDIO_GETBIGGEO or so.
I think the code for it should be deleted from the kernel.)

Andries


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[David Woodhouse]

aeb@veritas.com said:
> A modern fdisk will use the values for heads and sectors/track given
> by HDIO_GETGEO, but ignore the value for cylinders.

> Indeed, since cylinders is a 16-bit field and the number of cylinders
> can be larger than 65535, the value may be truncated, and is to be
> considered worthless.

> Instead, the number of cylinders is computed as BLKGETSIZE/(H*S).

What if BLKGETSIZE/(H*S) isn't an integer?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[Andries Brouwer]

On Mon, May 22, 2000 at 03:21:53PM +0100, David Woodhouse wrote:

> aeb@veritas.com said:
> > A modern fdisk will use the values for heads and sectors/track given
> > by HDIO_GETGEO, but ignore the value for cylinders.
> 
> > Instead, the number of cylinders is computed as BLKGETSIZE/(H*S).

> What if BLKGETSIZE/(H*S) isn't an integer?

/ is the C operator. It rounds down.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[David Woodhouse]

aeb@veritas.com said:
> > What if BLKGETSIZE/(H*S) isn't an integer?
> / is the C operator. It rounds down. 

Sorry, what I meant to say was:

What if (BLKGETSIZE / (H*S)) * (H*S) != BLKGETSIZE?

Is there anything that's likely to get confused by that?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[Andries Brouwer]

On Mon, May 22, 2000 at 04:47:16PM +0100, David Woodhouse wrote:

> aeb@veritas.com said:
> > > What if BLKGETSIZE/(H*S) isn't an integer?
> > / is the C operator. It rounds down. 
> 
> Sorry, what I meant to say was:
> 
> What if (BLKGETSIZE / (H*S)) * (H*S) != BLKGETSIZE?
> 
> Is there anything that's likely to get confused by that?

No. It happens all the time:

# hdparm -g /dev/hda
 geometry     = 2100/255/63, sectors = 33750864, start = 0

and 2100*255*63 = 33736500 < 33750864.
It just means that if you use an fdisk that likes partitions
to start and end on cylinder boundaries, the last partial
cylinder is wasted. In this case that would be 7 MB.

Andries



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: HDIO_GETGEO vs. BLKGETSIZE

[Andre Hedrick]

If we have a superior answer over the "HDIO_GETBIGGEO" kludge, I am up for
change.  I would ask it to stay until we verify that the newest changes
are what we desire........after that.....rip it......

On Mon, 22 May 2000, Andries Brouwer wrote:

> On Mon, May 22, 2000 at 01:06:17PM +0100, David Woodhouse wrote:
> 
> > Is it permitted for a driver to returns CHS values for HDIO_GETGEO which, 
> > when multiplied together, don't match the value returned by BLKGETSIZE?
> 
> Yes - HDIO_GETGEO may contain whatever you want.
> A modern fdisk will use the values for heads and sectors/track
> given by HDIO_GETGEO, but ignore the value for cylinders.
> 
> Indeed, since cylinders is a 16-bit field and the number of cylinders
> can be larger than 65535, the value may be truncated, and is to be
> considered worthless.
> 
> Instead, the number of cylinders is computed as BLKGETSIZE/(H*S).
> (Thus, there is no need for a new ioctl HDIO_GETBIGGEO or so.
> I think the code for it should be deleted from the kernel.)
> 
> Andries
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
The Linux ATA/IDE guy



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org