hd_geometry question.

hd_geometry question.

[Martin Schwidefsky]

Hi,
I have a question about the start field in the hd_geometry structure. We used

	geo->start = device->major_info->gendisk.part[MINOR(kdev)].start_sect
		>> device->sizes.s2b_shift;

in the old dasd driver but now we use

	geo.start = get_start_sect(kdev);

to set the start field. One variant is wrong because the start sector differ if
the block size is not 512 byte. The first variant calculates the start sector
based on physical blocks (e.g. with 4096 bytes instead of 512 bytes). The
second variant calulcates a "soft" start sector based on logical 512 byte
blocks. Whats correct, first or second variant ?? I tend to favor the first
variant because struct hd_geometry describes the physical geometry
(number of heads, sectors, cylinders and start sector) but I am not 100%
sure about it.

blue skies,
  Martin.

Re: hd_geometry question.

[Andre Hedrick]

Martin,

Are you looking at how the IDEMA proposal will be addressed in Linux ?
This beign 4096byte physical with 512byte logical and failure to do a full
8 sector logical write wil cause a read-write-modify to the physical.

Cheers,

On Mon, 1 Jul 2002, Martin Schwidefsky wrote:

> Hi,
> I have a question about the start field in the hd_geometry structure. We used
> 
> 	geo->start = device->major_info->gendisk.part[MINOR(kdev)].start_sect
> 		>> device->sizes.s2b_shift;
> 
> in the old dasd driver but now we use
> 
> 	geo.start = get_start_sect(kdev);
> 
> to set the start field. One variant is wrong because the start sector differ if
> the block size is not 512 byte. The first variant calculates the start sector
> based on physical blocks (e.g. with 4096 bytes instead of 512 bytes). The
> second variant calulcates a "soft" start sector based on logical 512 byte
> blocks. Whats correct, first or second variant ?? I tend to favor the first
> variant because struct hd_geometry describes the physical geometry
> (number of heads, sectors, cylinders and start sector) but I am not 100%
> sure about it.
> 
> blue skies,
>   Martin.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: hd_geometry question.

[Andries Brouwer]

On Mon, Jul 01, 2002 at 06:02:07PM +0200, Martin Schwidefsky wrote:

> I have a question about the start field in the hd_geometry structure. We used
> 
> 	geo->start = device->major_info->gendisk.part[MINOR(kdev)].start_sect
> 		>> device->sizes.s2b_shift;
> 
> in the old dasd driver but now we use
> 
> 	geo.start = get_start_sect(kdev);
> 
> to set the start field. One variant is wrong because the start sector differ if
> the block size is not 512 byte. The first variant calculates the start sector
> based on physical blocks (e.g. with 4096 bytes instead of 512 bytes). The
> second variant calulcates a "soft" start sector based on logical 512 byte
> blocks. Whats correct, first or second variant ?? I tend to favor the first
> variant because struct hd_geometry describes the physical geometry
> (number of heads, sectors, cylinders and start sector) but I am not 100%
> sure about it.

About a partition one wants to know start and length.
About a full disk one wants to know size, and perhaps a (fake) geometry.

The vital partition data cannot depend on obscure hardware info.
So, the units used must be well-known. Earlier, everything was in
512-byte sectors, but there are a few places where that is inconvenient
or unnatural, and now that one has more than 2^32 sectors and 64 bits
are needed anyway, things are measured in bytes.

That the start field comes with the HDIO_GETGEO ioctl and the size with
the BLKGETSIZE ioctl is due to history. Both are given in 512-byte sectors.
BLKGETSIZE64 gives bytes.

Andries

Re: hd_geometry question.

[Martin Schwidefsky]

>About a partition one wants to know start and length.
>About a full disk one wants to know size, and perhaps a (fake) geometry.
>
>The vital partition data cannot depend on obscure hardware info.
>So, the units used must be well-known. Earlier, everything was in
>512-byte sectors, but there are a few places where that is inconvenient
>or unnatural, and now that one has more than 2^32 sectors and 64 bits
>are needed anyway, things are measured in bytes.
>
>That the start field comes with the HDIO_GETGEO ioctl and the size with
>the BLKGETSIZE ioctl is due to history. Both are given in 512-byte sectors.
>BLKGETSIZE64 gives bytes.

Just to make sure I got that right, HDIO_GETGEO delivers a FAKE geometry
based on the assumption that the sector size is 512 bytes ?

blue skies,
   Martin

Re: hd_geometry question.

[jw schultz]

On Tue, Jul 02, 2002 at 11:16:06AM +0200, Martin Schwidefsky wrote:
> 
> >About a partition one wants to know start and length.
> >About a full disk one wants to know size, and perhaps a (fake) geometry.
> >
> >The vital partition data cannot depend on obscure hardware info.
> >So, the units used must be well-known. Earlier, everything was in
> >512-byte sectors, but there are a few places where that is inconvenient
> >or unnatural, and now that one has more than 2^32 sectors and 64 bits
> >are needed anyway, things are measured in bytes.
> >
> >That the start field comes with the HDIO_GETGEO ioctl and the size with
> >the BLKGETSIZE ioctl is due to history. Both are given in 512-byte sectors.
> >BLKGETSIZE64 gives bytes.
> 
> Just to make sure I got that right, HDIO_GETGEO delivers a FAKE geometry
> based on the assumption that the sector size is 512 bytes ?

Fake because almost all non-removable disks made in the last
decade have not had a fixed number of sectors per track.  If
the disk accepts positioning based on head,cylinder,sector
it has to be translated by the controller (the circuit board
attached to the drive) into a linear address and then into
the real h,c,s values.

Geometry info is mostly a relic from before zone recording
when filesystems were tuned for geometry and when drives
didn't accept linear addressing.  Andre will probably come
back with a list of drives that still don't accept linear
addresses ;-).

More on this fakeness of geometry belongs offline as it is OT.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: hd_geometry question.

[Andries Brouwer]

On Tue, Jul 02, 2002 at 11:16:06AM +0200, Martin Schwidefsky wrote:

> >About a partition one wants to know start and length.
> >About a full disk one wants to know size, and perhaps a (fake) geometry.
> >
> >The vital partition data cannot depend on obscure hardware info.
> >So, the units used must be well-known. Earlier, everything was in
> >512-byte sectors, but there are a few places where that is inconvenient
> >or unnatural, and now that one has more than 2^32 sectors and 64 bits
> >are needed anyway, things are measured in bytes.
> >
> >That the start field comes with the HDIO_GETGEO ioctl and the size with
> >the BLKGETSIZE ioctl is due to history. Both are given in 512-byte sectors.
> >BLKGETSIZE64 gives bytes.

> Just to make sure I got that right, HDIO_GETGEO delivers a FAKE geometry
> based on the assumption that the sector size is 512 bytes ?

I am tempted to just answer "yes".
You capitalize FAKE, as if that is an interesting and important part.
But non-fake geometries do not exist. Let me give a somewhat more
explicit answer.

HDIO_GETGEO delivers several things, namely a starting address and a geometry.

The starting address is in 512-byte sector units, and is entirely
independent of any hardware properties.
Also the size returned by BLKGETSIZE is in 512-byte sector units.

The geometry has, for the common IDE and SCSI cases, been fake for the last
ten years or so, since IDE and SCSI disks do not have a geometry. 
The geometry consists of cylinders / heads / sectors-per-track.
In reality of course the number of physical sectors per track is not constant:
there are more sectors per track on the outer rim. Thus, such a geometry does
not have any physical significance.
The purpose of these ridiculous numbers is only to fill certain fields
in a DOS-type partition table. This geometry is of interest only on a
disk that is shared with DOS or some similar operating system, where
it is important that Linux and DOS do interpret the partition table
in the same way.

The cylinder field in the struct returned by HDIO_GETGEO is obsolete
and must not be used. (Because the value is trancated and nobody needs
it - user space can compute it when desired, like *fdisk does, but
the number obtained is purely phantasy, eye-candy only, and does not
play any role in the interpretation of partition tables.)

The heads and sectors-per-track values are those specified by the user
on the command line, or guessed from the partition table, or returned
by the IDENTIFY command to the IDE drive, or returned by the biosparam
routine of the SCSI drive. (Or ...)
The sectors of this sectors-per-track value are sectors of unknown size,
namely the size that DOS would use in its partition table.
Usually one sets heads to 16 and sectors per track to 63.

The ATA standard defines a sector as 256 words (512 bytes), so
what the IDENTIFY command returns is in terms of 512-byte sectors.
Everybody else follows.

It is rumoured that certain MO disks with a hardware sector size
of 2048 bytes have partition tables in units of 2048-byte sectors.

All these things are of no concern to the kernel. It is up to
*fdisk, and perhaps some boot loader, to worry about such things.

Andries

Re: hd_geometry question.

[Roman Zippel]

Hi,

On Wed, 3 Jul 2002, Andries Brouwer wrote:

> It is rumoured that certain MO disks with a hardware sector size
> of 2048 bytes have partition tables in units of 2048-byte sectors.

Why is it a rumour? AFAIK under DOS/Windows the partition table is in
units of sector size.

bye, Roman

Re: hd_geometry question.

[Andries Brouwer]

On Thu, Jul 04, 2002 at 01:48:33AM +0200, Roman Zippel wrote:

> > It is rumoured that certain MO disks with a hardware sector size
> > of 2048 bytes have partition tables in units of 2048-byte sectors.
> 
> Why is it a rumour? AFAIK under DOS/Windows the partition table is in
> units of sector size.

I assume you mean hardware sector size.

Yes, that is what I wrote in
	http://www.win.tue.nl/~aeb/partitions/partition_tables-2.html#ss2.1

Sector size different from 512 is rare, so it is a bit difficult to find
precise details. Do you have docs?

Re: hd_geometry question.

[Andre Hedrick]

Well it just got adopted to 528 --- whoop !

On Thu, 4 Jul 2002, Andries Brouwer wrote:

> On Thu, Jul 04, 2002 at 01:48:33AM +0200, Roman Zippel wrote:
> 
> > > It is rumoured that certain MO disks with a hardware sector size
> > > of 2048 bytes have partition tables in units of 2048-byte sectors.
> > 
> > Why is it a rumour? AFAIK under DOS/Windows the partition table is in
> > units of sector size.
> 
> I assume you mean hardware sector size.
> 
> Yes, that is what I wrote in
> 	http://www.win.tue.nl/~aeb/partitions/partition_tables-2.html#ss2.1
> 
> Sector size different from 512 is rare, so it is a bit difficult to find
> precise details. Do you have docs?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
Linux Serial ATA Solutions
LAD Storage Consulting Group

Re: hd_geometry question.

[Alan Cox]

> On Wed, 3 Jul 2002, Andries Brouwer wrote:
> 
> > It is rumoured that certain MO disks with a hardware sector size
> > of 2048 bytes have partition tables in units of 2048-byte sectors.
> 
> Why is it a rumour? AFAIK under DOS/Windows the partition table is in
> units of sector size.

Yes. I have Fujitsu M/O drives with this property.

Re: hd_geometry question.

[Martin Schwidefsky]

>> Just to make sure I got that right, HDIO_GETGEO delivers a FAKE geometry
>> based on the assumption that the sector size is 512 bytes ?
>
>I am tempted to just answer "yes".
>You capitalize FAKE, as if that is an interesting and important part.
>But non-fake geometries do not exist. Let me give a somewhat more
>explicit answer.

Thanks for the long answer, it helped me to understand the situation.
Our problem is that we do have a REAL geometry for the dasd disks on
a s/390. And for the old dasd driver in the 2.4 series HDIO_GETGEO
delivers the real geometry of the disk measured in physical blocks
which is not necessarily 512 bytes. Most often it is 4096 bytes.
The problem now is that if geo.start is REQUIRED to be measured in
512 byte blocks we have to incompatibly change the HDIO_GETGEO ioctl.
Not nice.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: hd_geometry question.

[Andries Brouwer]

On Wed, Jul 03, 2002 at 10:13:19AM +0200, Martin Schwidefsky wrote:

> The problem now is that if geo.start is REQUIRED to be measured in
> 512 byte blocks we have to incompatibly change the HDIO_GETGEO ioctl.
> Not nice.

Yes, unfortunate. But the change will break very little, if anything.
Leave things as they are in 2.4, and change in 2.5.
Many years from now, when people upgrade from 2.4 to 2.6,
this will be one of the minor differences.

And maybe HDIO_GETGEO will be removed entirely.

Andries