Disk geometry from /sys

Disk geometry from /sys

[Francis Moreau]

Hi,

I'm trying to know the geometry of my hard disk from a bash script
and that's the reason I'm looking in /sys. The reason is that I'd like
to figure out the size of a cylinder without doing a
ioctl(bdev, HDIO_GETGEO, &geo)

Unfortunately I can't find anything useful and this is certainly a sign
that I'm doing something wrong.

Or maybe can I simply assume from my script that the geometry
is always heads=255 and the number of sectors per track is 63 for all
disks.

Looking at parted(8) source code, I  can find this:

/* The GETGEO ioctl is no longer useful (as of linux 2.6.x).  We could
 * still use it in 2.4.x, but this is contentious.  Perhaps we should
 * move to EDD. */

Could anybody give me some advices ?
-- 
Francis

Re: Disk geometry from /sys

[Lennart Sorensen]

On Wed, Apr 09, 2008 at 10:53:36PM +0200, Francis Moreau wrote:
> I'm trying to know the geometry of my hard disk from a bash script
> and that's the reason I'm looking in /sys. The reason is that I'd like
> to figure out the size of a cylinder without doing a
> ioctl(bdev, HDIO_GETGEO, &geo)
> 
> Unfortunately I can't find anything useful and this is certainly a sign
> that I'm doing something wrong.
> 
> Or maybe can I simply assume from my script that the geometry
> is always heads=255 and the number of sectors per track is 63 for all
> disks.

Many compact flash cards will report 16 heads, and 16 or 32 sectors
per track.  Compact flash can of course connect as an IDE drive, so they
are worth supporting (I keep trying to get the grub guys to accept my
patch to fix their code that also assumed all disks have 63 sectors per
track if they use LBA, but which is false since compact flash also
supports LBA even with smaller sizes).

Simplest way to find out what geometry a disk pretents to have is to ask
fdisk, and since the only use for the information is when creating
partitions, then fdisk's opinion is really all that seems to matter.  Of
course partitions can start and end anywhere so the total size is
actually all that really matters.

For example:
# fdisk -l /dev/hda

Disk /dev/hda: 260 MB, 260571136 bytes
16 heads, 32 sectors/track, 994 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

   Device Boot      Start         End      Blocks   Id  System
 /dev/hda1               1          40       10224   83  Linux
 /dev/hda2              41          80       10240   83  Linux
 /dev/hda3              81         994      233984   83  Linux

So no assuming 255 and 63 is not a good idea.  Large disks tend to do it
since 255 heads and 63 sectors per track is the maximum supported, and
hence allowed them to get as much space in each "cylinder".

> Looking at parted(8) source code, I  can find this:
> 
> /* The GETGEO ioctl is no longer useful (as of linux 2.6.x).  We could
>  * still use it in 2.4.x, but this is contentious.  Perhaps we should
>  * move to EDD. */
> 
> Could anybody give me some advices ?

Why do you want to know what cylinder size the hard disk pretents to
have?  What use could it be?  Harddisks have varying numbers of sectors
per cylinder depending on how far out you are from the center of the
disk, but since software used to expect a simple X head, Y tracks, Z
sectors per track, they lie about it and pretend to have some number of
each (usually 255 heads (as if), 63 sectors per track (not likely with
todays densities), and thousands of cylinders), and even with all that
added up it still works out to less than the actual size of a modern
drive.  All that matters on a modern drive is the total number of
sectors since all access is done by requesting a specific sector number
starting from the begining of the drive.  Where it is physically located
is none of software's business, and it may not even be adjacent to the
sector with a number right next to the requested one due to defect
management and various optimizations.

-- 
Len Sorensen

Re: Disk geometry from /sys

[Alan Cox]

> Why do you want to know what cylinder size the hard disk pretents to
> have?  What use could it be?  Harddisks have varying numbers of sectors

It matters on a CHS addressed device - vaguely.

> drive.  All that matters on a modern drive is the total number of
> sectors since all access is done by requesting a specific sector number
> starting from the begining of the drive.  Where it is physically located
> is none of software's business, and it may not even be adjacent to the
> sector with a number right next to the requested one due to defect
> management and various optimizations.

And some other OS's make certain assumptions about layout that must agree
with that OS view of the disk. A good general rule is to believe the
partition table information if present and if not use SG_IO to issue an
IDENTIFY to any ATA or CFA drive to see how it has mapped the device.

Even better make use fo the existing tools whenever possible - disk
partitioning is more like magic than science

Alan

Re: Disk geometry from /sys

[Bernd Eckenfels]

In article <20080409212840.GB2160@csclub.uwaterloo.ca> you wrote:
> Simplest way to find out what geometry a disk pretents to have is to ask
> fdisk, and since the only use for the information is when creating
> partitions, then fdisk's opinion is really all that seems to matter.

Unfortunatelly there is also bios' view of the geometry, which is especially
a problem for boot loaders. Just another hint:

# lilo -T geom

    bios=0x00, cylinders=80, heads=2, sectors=18
        (  1.44Mb         2,880 sectors)        C:H:S supported (PC bios)

BIOS reports 2 hard drives
    bios=0x80, cylinders=527, heads=255, sectors=63     vol-ID: 2C731DD1
        (  4.33Gb     8,467,199 sectors)        LBA32 supported (EDD bios)
    bios=0x81, cylinders=527, heads=255, sectors=63
        (  4.33Gb     8,467,199 sectors)        LBA32 supported (EDD bios)

(um yes my system is somewhat outdated, thats an adaptec scsi bios.

Gruss
Bernd

Re: Disk geometry from /sys

[Lennart Sorensen]

On Thu, Apr 10, 2008 at 12:16:12AM +0200, Bernd Eckenfels wrote:
> Unfortunatelly there is also bios' view of the geometry, which is especially
> a problem for boot loaders. Just another hint:
> 
> # lilo -T geom
> 
>     bios=0x00, cylinders=80, heads=2, sectors=18
>         (  1.44Mb         2,880 sectors)        C:H:S supported (PC bios)
> 
> BIOS reports 2 hard drives
>     bios=0x80, cylinders=527, heads=255, sectors=63     vol-ID: 2C731DD1
>         (  4.33Gb     8,467,199 sectors)        LBA32 supported (EDD bios)
>     bios=0x81, cylinders=527, heads=255, sectors=63
>         (  4.33Gb     8,467,199 sectors)        LBA32 supported (EDD bios)
> 
> (um yes my system is somewhat outdated, thats an adaptec scsi bios.

Just use LBA.  Both lilo and grub can, in which case they no longer care
about the geometry at all.

-- 
Len Sorensen

Re: Disk geometry from /sys

[Francis Moreau]

Hello,

On Wed, Apr 9, 2008 at 11:28 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
>  Many compact flash cards will report 16 heads, and 16 or 32 sectors
>  per track.  Compact flash can of course connect as an IDE drive, so they
>  are worth supporting (I keep trying to get the grub guys to accept my
>  patch to fix their code that also assumed all disks have 63 sectors per
>  track if they use LBA, but which is false since compact flash also
>  supports LBA even with smaller sizes).
>

Ok so assuming 255 heads seems not to be a good idea.

>  Simplest way to find out what geometry a disk pretents to have is to ask
>  fdisk,

or to create a new entry in /sys:

/sys/block/sda/geometry/heads

?

> and since the only use for the information is when creating
>  partitions, then fdisk's opinion is really all that seems to matter.  Of
>  course partitions can start and end anywhere so the total size is
>  actually all that really matters.
>

I'm not sure about that. Some bootloaders have constraint on the start
and end of a partition. It assume they're aligned on a cylinder size
boundary. I got this warning from sfdisk(8).

Thanks
-- 
Francis

Re: Disk geometry from /sys

[Mark Lord]

Francis Moreau wrote:
> Hi,
> 
> I'm trying to know the geometry of my hard disk from a bash script
> and that's the reason I'm looking in /sys. The reason is that I'd like
> to figure out the size of a cylinder without doing a
> ioctl(bdev, HDIO_GETGEO, &geo)

$ DEV=/dev/sda
$ GEOM="`/sbin/hdparm -g $DEV | awk '{print $3}'`"
$ echo $GEOM
19457/255/63
$

Re: Disk geometry from /sys

[Francis Moreau]

Hi

On Wed, Apr 9, 2008 at 11:57 PM, Mark Lord <lkml@rtr.ca> wrote:
> > I'm trying to know the geometry of my hard disk from a bash script
> > and that's the reason I'm looking in /sys. The reason is that I'd like
> > to figure out the size of a cylinder without doing a
> > ioctl(bdev, HDIO_GETGEO, &geo)
> >
>
>  $ DEV=/dev/sda
>  $ GEOM="`/sbin/hdparm -g $DEV | awk '{print $3}'`"
>  $ echo $GEOM
>  19457/255/63
>  $
>

Sure and you could the same with fdisk, sfdisk, parted outputs...

But that wasn't my point, sorry if it wasn't clear.

I was actually wondering why /sys/block/sda exports a lot of disk
features but the disk geometry. I was wondering if somthing like

/sys/block/sda/geometry/heads

could be useful...

-- 
Francis

Re: Disk geometry from /sys

[Mark Lord]

Francis Moreau wrote:
> Hi
> 
> On Wed, Apr 9, 2008 at 11:57 PM, Mark Lord <lkml@rtr.ca> wrote:
>>> I'm trying to know the geometry of my hard disk from a bash script
>>> and that's the reason I'm looking in /sys. The reason is that I'd like
>>> to figure out the size of a cylinder without doing a
>>> ioctl(bdev, HDIO_GETGEO, &geo)
>>>
>>  $ DEV=/dev/sda
>>  $ GEOM="`/sbin/hdparm -g $DEV | awk '{print $3}'`"
>>  $ echo $GEOM
>>  19457/255/63
>>  $
>>
> 
> Sure and you could the same with fdisk, sfdisk, parted outputs...
> 
> But that wasn't my point, sorry if it wasn't clear.
> 
> I was actually wondering why /sys/block/sda exports a lot of disk
> features but the disk geometry. I was wondering if somthing like
> 
> /sys/block/sda/geometry/heads
> 
> could be useful...
..

Probably not for going forward.  Except when partitioning,
the CHS info isn't really useful or needed for anything newer
than about 14 years old.

And there's already an ioctl for getting it.

So we could add more /sysfs bloat for it, I suppose, but..
 

Re: Disk geometry from /sys

[linux-os (Dick Johnson)]

On Wed, 9 Apr 2008, Francis Moreau wrote:

> Hi,
>
> I'm trying to know the geometry of my hard disk from a bash script
> and that's the reason I'm looking in /sys. The reason is that I'd like
> to figure out the size of a cylinder without doing a
> ioctl(bdev, HDIO_GETGEO, &geo)
>
> Unfortunately I can't find anything useful and this is certainly a sign
> that I'm doing something wrong.
>
> Or maybe can I simply assume from my script that the geometry
> is always heads=255 and the number of sectors per track is 63 for all
> disks.
>
> Looking at parted(8) source code, I  can find this:
>
> /* The GETGEO ioctl is no longer useful (as of linux 2.6.x).  We could
> * still use it in 2.4.x, but this is contentious.  Perhaps we should
> * move to EDD. */
>
> Could anybody give me some advices ?
> -- 
> Francis
> --

It becomes, as you say contentious, because with disk drives
manufactured during the past ten or so years, anything about
the physical geometry is fictitious. The PC BIOS continues to
calculate C/H/S because that's what BIOS interrupt 0x13 uses
to boot the machine. The boot code needs to know what the
BIOS claims or else it may fail to boot. However, once Linux
is up, there are no C/H/S unless they were invented --and
hopefully, the same as what the BIOS claims.

In the BIOS interrupt 0x13 code, the maximum number of heads
that will fit in the register is 255. The maximum number of
sectors that will fit in the partial register scheme is 63.
That leaves the cylinders as the only remaining variable for
large media. However, the BIOS only needs to boot the machine.
There may be many more cylinders than your initial guess and
the BIOS can only use 10 bits of the cylinder number. If you
are writing boot code, perhaps making the next GRUB or whatever
then you can use the numbers you suggested. However if not, you
have no need to learn the actual disk geometry and it is not
even shown in many disk-drive data sheets because the number
of sectors on the outside tracks is now greater than the ones
on the inside tracks to maintain the same areal bit density and
maximize the storage capacity.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Disk geometry from /sys

[Francis Moreau]

Hi,

On Thu, Apr 10, 2008 at 2:22 PM, linux-os (Dick Johnson)
<linux-os@analogic.com> wrote:
>
>  It becomes, as you say contentious, because with disk drives
>  manufactured during the past ten or so years, anything about
>  the physical geometry is fictitious. The PC BIOS continues to
>  calculate C/H/S because that's what BIOS interrupt 0x13 uses
>  to boot the machine. The boot code needs to know what the
>  BIOS claims or else it may fail to boot. However, once Linux
>  is up, there are no C/H/S unless they were invented --and
>  hopefully, the same as what the BIOS claims.
>

Some bootloaders want the partition starts to be aligned on a
cylinder size boundary. Try for example to setup a disk partition
table by using parted. It almost always complains about the
the size of the parts I try to create and suggest me others. The
same stands for sfdisk except that it just gives you some
warnings.

Thanks
-- 
Francis

Re: Disk geometry from /sys

[Bill Davidsen]

Francis Moreau wrote:
> Hi,
> 
> I'm trying to know the geometry of my hard disk from a bash script
> and that's the reason I'm looking in /sys. The reason is that I'd like
> to figure out the size of a cylinder without doing a
> ioctl(bdev, HDIO_GETGEO, &geo)
> 
> Unfortunately I can't find anything useful and this is certainly a sign
> that I'm doing something wrong.
> 
> Or maybe can I simply assume from my script that the geometry
> is always heads=255 and the number of sectors per track is 63 for all
> disks.
> 
> Looking at parted(8) source code, I  can find this:
> 
> /* The GETGEO ioctl is no longer useful (as of linux 2.6.x).  We could
>  * still use it in 2.4.x, but this is contentious.  Perhaps we should
>  * move to EDD. */
> 
> Could anybody give me some advices ?

Given that the connection between any modern disk geometry and the 
assumption of a fixed number of sectors per track is pretty tenuous, I'm 
not sure any of the sizes, BIOS, boot program, or OS, are more than 
convention anymore.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Disk geometry from /sys

[Seewer Philippe]

Hi Francis, 

Francis Moreau wrote:
> Hi,
> 
> I'm trying to know the geometry of my hard disk from a bash script
> and that's the reason I'm looking in /sys. The reason is that I'd like
> to figure out the size of a cylinder without doing a
> ioctl(bdev, HDIO_GETGEO, &geo)
> 
> Unfortunately I can't find anything useful and this is certainly a sign
> that I'm doing something wrong.
> 
> Or maybe can I simply assume from my script that the geometry
> is always heads=255 and the number of sectors per track is 63 for all
> disks.
> 
> Looking at parted(8) source code, I  can find this:
> 
> /* The GETGEO ioctl is no longer useful (as of linux 2.6.x).  We could
>  * still use it in 2.4.x, but this is contentious.  Perhaps we should
>  * move to EDD. */
> 
> Could anybody give me some advices ?

As you've problably seen from the other answers, disk geometry is (except for a few older devices) unneeded inside the Linux kernel. I'd say thats the reason why there's no sysfs export and I'd further guess disk geometry is an artifact most would like to get rid of (or pushed into userspace).

Anyway, if you really need it, try the patch below. Should apply cleanly to version 2.6.23.1 and gives you a geometry/ directory for each block device providing the getgeo function. It adds a setgeo counterpart for some subsystems as well, allowing 'echo something > ...' so please be careful.

---
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/block/Makefile linux-2.6.23.1/block/Makefile
--- linux-2.6.23.1-vanilla/block/Makefile	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/block/Makefile	2007-10-19 11:51:54.000000000 +0200
@@ -2,7 +2,7 @@
 # Makefile for the kernel block layer
 #
 
-obj-$(CONFIG_BLOCK) := elevator.o ll_rw_blk.o ioctl.o genhd.o scsi_ioctl.o
+obj-$(CONFIG_BLOCK) := elevator.o ll_rw_blk.o ioctl.o genhd.o gengeo.o scsi_ioctl.o
 
 obj-$(CONFIG_BLK_DEV_BSG)	+= bsg.o
 obj-$(CONFIG_IOSCHED_NOOP)	+= noop-iosched.o
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/block/gengeo.c linux-2.6.23.1/block/gengeo.c
--- linux-2.6.23.1-vanilla/block/gengeo.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.23.1/block/gengeo.c	2007-10-19 11:51:54.000000000 +0200
@@ -0,0 +1,153 @@
+/**
+ *  generic geometry handling. utility for gendisk.c
+ */
+
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/genhd.h>
+#include <linux/kernel.h>
+#include <linux/blkdev.h>
+#include <linux/kmod.h>
+#include <linux/hdreg.h>
+
+/*
+ * General show method invoked by attribute->show.
+ *
+ * Gets the "real" block device, invokes getgeo and delegates output
+ * to the corresponding format function.
+ */
+static ssize_t disk_geom_attr_show(struct gendisk *disk, char *buf,
+				   ssize_t(*format) (const struct hd_geometry *
+						     geo, char *buf))
+{
+	ssize_t ret = -EIO;
+
+	struct hd_geometry geo;
+	struct block_device *bdev = bdget_disk(disk, 0);
+	blkdev_get(bdev, FMODE_READ, 0);
+
+	if (bdev) {
+		geo.start = get_start_sect(bdev);
+		disk->fops->getgeo(bdev, &geo);
+		ret = (*format) (&geo, buf);
+	} else {
+		ret = -ENODEV;
+	}
+	return ret;
+}
+
+/*
+ * General store method invoked by attribute->store.
+ *
+ * Gets the "real" block device, invokes getgeo, delegates input to
+ * the corresponding set function and invokes setgeo.
+ */
+static ssize_t disk_geom_attr_store(struct gendisk *disk, const char *buf,
+				    size_t count,
+				    int (*set) (struct hd_geometry * geo,
+						unsigned long value))
+{
+	ssize_t ret = 0;
+	char *endp;
+	unsigned long value;
+	struct hd_geometry geo;
+	struct block_device *bdev = bdget_disk(disk, 0);
+	blkdev_get(bdev, FMODE_READ, 0);
+
+	value = simple_strtoul(buf, &endp, 0);
+	if (endp == buf)
+		return -EINVAL;
+
+	if (bdev) {
+		geo.start = get_start_sect(bdev);
+		disk->fops->getgeo(bdev, &geo);
+		if ((ret = (*set) (&geo, value)) == 0) {
+			disk->fops->setgeo(bdev, &geo);
+			ret = count;
+		}
+	} else {
+		ret = -ENODEV;
+	}
+	return ret;
+}
+
+/* Generate a show function for field */
+#define DISKGEOM_SHOW(field, format_string) \
+static ssize_t disk_geom_format_##field(const struct hd_geometry *geo, char *buf) \
+{ \
+  return sprintf(buf, format_string, geo->field); \
+} \
+static ssize_t disk_geom_show_##field(struct gendisk * disk, char *buf) \
+{ \
+  return disk_geom_attr_show(disk, buf, disk_geom_format_##field); \
+} \
+static struct disk_attribute disk_geom_attr_ro_##field = __ATTR(field, S_IRUGO, disk_geom_show_##field, NULL);
+
+/* Generate a store function for field */
+#define DISKGEOM_STORE(field, max) \
+static int disk_geom_set_##field(struct hd_geometry *geo, unsigned long value) \
+{ \
+  if (value > max) \
+    return -EINVAL; \
+  geo->field = value; \
+  return 0; \
+} \
+static ssize_t disk_geom_store_##field(struct gendisk *disk, const char *buf, size_t count) \
+{ \
+  return disk_geom_attr_store(disk, buf, count, disk_geom_set_##field); \
+} \
+static struct disk_attribute disk_geom_attr_rw_##field = __ATTR(field, S_IRUGO | S_IWUSR, disk_geom_show_##field, disk_geom_store_##field);
+
+DISKGEOM_SHOW(heads, "%d\n");
+DISKGEOM_SHOW(sectors, "%d\n");
+DISKGEOM_SHOW(cylinders, "%d\n");
+DISKGEOM_SHOW(start, "%ld\n");
+
+DISKGEOM_STORE(heads, 255);
+DISKGEOM_STORE(sectors, 63);
+DISKGEOM_STORE(cylinders, 65535);
+
+static struct attribute *disk_geom_attrs_ro[] = {
+	&disk_geom_attr_ro_heads.attr,
+	&disk_geom_attr_ro_sectors.attr,
+	&disk_geom_attr_ro_cylinders.attr,
+	&disk_geom_attr_ro_start.attr,
+	NULL
+};
+
+static struct attribute *disk_geom_attrs_rw[] = {
+	&disk_geom_attr_rw_heads.attr,
+	&disk_geom_attr_rw_sectors.attr,
+	&disk_geom_attr_rw_cylinders.attr,
+	&disk_geom_attr_ro_start.attr,
+	NULL
+};
+
+static struct attribute_group disk_geom_ro_attrgroup = {
+	.name = "geometry",
+	.attrs = disk_geom_attrs_ro,
+};
+
+static struct attribute_group disk_geom_rw_attrgroup = {
+	.name = "geometry",
+	.attrs = disk_geom_attrs_rw,
+};
+
+/* function called from add_disk in genhd */
+int add_geometry(struct gendisk *disk)
+{
+	if (disk->fops->setgeo) {
+		return sysfs_create_group(&disk->kobj, &disk_geom_rw_attrgroup);
+	} else {
+		return sysfs_create_group(&disk->kobj, &disk_geom_ro_attrgroup);
+	}
+}
+
+/* function called from disk_release in genhd */
+void remove_geometry(struct gendisk *disk)
+{
+	if (disk->fops->setgeo)
+		sysfs_remove_group(&disk->kobj, &disk_geom_rw_attrgroup);
+	else
+		sysfs_remove_group(&disk->kobj, &disk_geom_ro_attrgroup);
+}
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/block/genhd.c linux-2.6.23.1/block/genhd.c
--- linux-2.6.23.1-vanilla/block/genhd.c	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/block/genhd.c	2007-10-19 11:51:54.000000000 +0200
@@ -168,6 +168,10 @@ static int exact_lock(dev_t dev, void *d
 	return 0;
 }
 
+/* Extern in gengeo.c */
+extern int add_geometry(struct gendisk *disk);
+extern void remove_geometry(struct gendisk *disk);
+
 /**
  * add_disk - add partitioning information to kernel list
  * @disk: per-device partitioning information
@@ -181,6 +185,8 @@ void add_disk(struct gendisk *disk)
 	blk_register_region(MKDEV(disk->major, disk->first_minor),
 			    disk->minors, NULL, exact_match, exact_lock, disk);
 	register_disk(disk);
+	if (disk->fops->getgeo)
+	        add_geometry(disk);
 	blk_register_queue(disk);
 }
 
@@ -521,6 +527,7 @@ static void disk_release(struct kobject 
 	struct gendisk *disk = to_disk(kobj);
 	kfree(disk->random);
 	kfree(disk->part);
+	remove_geometry(disk);
 	free_disk_stats(disk);
 	kfree(disk);
 }
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/drivers/ide/ide-disk.c linux-2.6.23.1/drivers/ide/ide-disk.c
--- linux-2.6.23.1-vanilla/drivers/ide/ide-disk.c	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/drivers/ide/ide-disk.c	2007-10-19 11:51:54.000000000 +0200
@@ -1183,6 +1183,17 @@ static int idedisk_getgeo(struct block_d
 	return 0;
 }
 
+static int idedisk_setgeo(struct block_device *bdev, struct hd_geometry *geo)
+{
+	struct ide_disk_obj *idkp = ide_disk_g(bdev->bd_disk);
+	ide_drive_t *drive = idkp->drive;
+
+	drive->bios_head = geo->heads;
+	drive->bios_sect = geo->sectors;
+	drive->bios_cyl  = geo->cylinders;
+	return 0;
+}
+
 static int idedisk_ioctl(struct inode *inode, struct file *file,
 			unsigned int cmd, unsigned long arg)
 {
@@ -1258,6 +1269,7 @@ static struct block_device_operations id
 	.release	= idedisk_release,
 	.ioctl		= idedisk_ioctl,
 	.getgeo		= idedisk_getgeo,
+	.setgeo		= idedisk_setgeo,
 	.media_changed	= idedisk_media_changed,
 	.revalidate_disk= idedisk_revalidate_disk
 };
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/drivers/scsi/sd.c linux-2.6.23.1/drivers/scsi/sd.c
--- linux-2.6.23.1-vanilla/drivers/scsi/sd.c	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/drivers/scsi/sd.c	2007-10-19 11:51:54.000000000 +0200
@@ -620,20 +620,38 @@ static int sd_getgeo(struct block_device
 	struct Scsi_Host *host = sdp->host;
 	int diskinfo[4];
 
-	/* default to most commonly used values */
-        diskinfo[0] = 0x40;	/* 1 << 6 */
-       	diskinfo[1] = 0x20;	/* 1 << 5 */
-       	diskinfo[2] = sdkp->capacity >> 11;
-	
-	/* override with calculated, extended default, or driver values */
-	if (host->hostt->bios_param)
-		host->hostt->bios_param(sdp, bdev, sdkp->capacity, diskinfo);
-	else
-		scsicam_bios_param(bdev, sdkp->capacity, diskinfo);
+	if (sdkp->heads && sdkp->sectors && sdkp->cylinders) {
+		geo->heads     = sdkp->heads;
+		geo->sectors   = sdkp->sectors;
+		geo->cylinders = sdkp->cylinders;
+	} else {
+		/* default to most commonly used values */
+		diskinfo[0] = 0x40;	/* 1 << 6 */
+		diskinfo[1] = 0x20;	/* 1 << 5 */
+		diskinfo[2] = sdkp->capacity >> 11;
+
+		/* override with calculated, extended default, or driver values */
+		if (host->hostt->bios_param)
+			host->hostt->bios_param(sdp, bdev, sdkp->capacity,
+						diskinfo);
+		else
+			scsicam_bios_param(bdev, sdkp->capacity, diskinfo);
+
+		geo->heads = diskinfo[0];
+		geo->sectors = diskinfo[1];
+		geo->cylinders = diskinfo[2];
+	}
+	return 0;
+}
+
+static int sd_setgeo(struct block_device *bdev, struct hd_geometry *geo)
+{
+	struct scsi_disk *sdkp = scsi_disk(bdev->bd_disk);
+
+	sdkp->heads     = geo->heads;
+	sdkp->sectors   = geo->sectors;
+	sdkp->cylinders = geo->cylinders;
 
-	geo->heads = diskinfo[0];
-	geo->sectors = diskinfo[1];
-	geo->cylinders = diskinfo[2];
 	return 0;
 }
 
@@ -881,6 +899,7 @@ static struct block_device_operations sd
 	.release		= sd_release,
 	.ioctl			= sd_ioctl,
 	.getgeo			= sd_getgeo,
+	.setgeo			= sd_setgeo,
 #ifdef CONFIG_COMPAT
 	.compat_ioctl		= sd_compat_ioctl,
 #endif
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/include/linux/fs.h linux-2.6.23.1/include/linux/fs.h
--- linux-2.6.23.1-vanilla/include/linux/fs.h	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/include/linux/fs.h	2007-10-19 11:51:54.000000000 +0200
@@ -1067,6 +1067,7 @@ struct block_device_operations {
 	int (*media_changed) (struct gendisk *);
 	int (*revalidate_disk) (struct gendisk *);
 	int (*getgeo)(struct block_device *, struct hd_geometry *);
+	int (*setgeo)(struct block_device *, struct hd_geometry *);
 	struct module *owner;
 };
 
diff -uprN -X linux-2.6.23.1-vanilla/Documentation/dontdiff linux-2.6.23.1-vanilla/include/scsi/sd.h linux-2.6.23.1/include/scsi/sd.h
--- linux-2.6.23.1-vanilla/include/scsi/sd.h	2007-10-12 18:43:44.000000000 +0200
+++ linux-2.6.23.1/include/scsi/sd.h	2007-10-19 12:01:58.000000000 +0200
@@ -44,6 +44,12 @@ struct scsi_disk {
 	unsigned	WCE : 1;	/* state of disk WCE bit */
 	unsigned	RCD : 1;	/* state of disk RCD bit, unused */
 	unsigned	DPOFUA : 1;	/* state of disk DPOFUA bit */
+
+
+	/* Disk geometry for overwrite */
+	unsigned char   heads;
+	unsigned char   sectors;
+	unsigned short  cylinders;
 };
 #define to_scsi_disk(obj) container_of(obj,struct scsi_disk,cdev)
 

Re: Disk geometry from /sys

[Francis Moreau]

Hi Seewer,

On Mon, Apr 14, 2008 at 2:57 PM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>
>  As you've problably seen from the other answers, disk geometry is (except
> for a few older devices) unneeded inside the Linux kernel.

Yes but I'm doing userspace stuff and that's the reason I was asking for the
sysfs thing.

> I'd say thats the
> reason why there's no sysfs export and I'd further guess disk geometry is an
> artifact most would like to get rid of (or pushed into userspace).
>

Well, I looked at sfdisk(8) and parted(8) source code and they all need the
geometry description. If I understood correctly the reason why is that it
'prefers' to align partition sizes/starts on a cylinder boundary because some
bootloaders probably use CHS addressing, but I'm really not sure.

>  Anyway, if you really need it, try the patch below. Should apply cleanly to
> version 2.6.23.1 and gives you a geometry/ directory for each block device
> providing the getgeo function. It adds a setgeo counterpart for some
> subsystems as well, allowing 'echo something > ...' so please be careful.
>

Thanks but I probably won't use it. Using sfdisk, for example, is a
more portable
way to get the geometry from a script.

-- 
Francis

Re: Disk geometry from /sys

[Seewer Philippe]

Hi,

Francis Moreau wrote:
> Hi Seewer,
> 
> On Mon, Apr 14, 2008 at 2:57 PM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>>  As you've problably seen from the other answers, disk geometry is (except
>> for a few older devices) unneeded inside the Linux kernel.
> 
> Yes but I'm doing userspace stuff and that's the reason I was asking for the
> sysfs thing.
> 
>> I'd say thats the
>> reason why there's no sysfs export and I'd further guess disk geometry is an
>> artifact most would like to get rid of (or pushed into userspace).
>>
> 
> Well, I looked at sfdisk(8) and parted(8) source code and they all need the
> geometry description. If I understood correctly the reason why is that it
> 'prefers' to align partition sizes/starts on a cylinder boundary because some
> bootloaders probably use CHS addressing, but I'm really not sure.
Yes indeed, mainly in the (w)intel world though.

> 
>>  Anyway, if you really need it, try the patch below. Should apply cleanly to
>> version 2.6.23.1 and gives you a geometry/ directory for each block device
>> providing the getgeo function. It adds a setgeo counterpart for some
>> subsystems as well, allowing 'echo something > ...' so please be careful.
>>
> 
> Thanks but I probably won't use it. Using sfdisk, for example, is a
> more portable
> way to get the geometry from a script.

Correct. Though be really careful which geometry you are requesting:

root@local:/# sfdisk -g /dev/sda
/dev/sda: 7296 cylinders, 255 heads, 63 sectors/track
root@local:/# sfdisk -G /dev/sda
/dev/sda: 116280 cylinders, 16 heads, 63 sectors/track

The first one is the kernels idea of a disks geometry which is probably 
as often correct as it's just plain wrong, versus the second one which 
tries to guess a disks geometry by looking at the current partition 
table. Which might be just as wrong since its only necessary for bios 
and/or bootloader. Really depends on what you need.

Cheers
Philippe

Re: Disk geometry from /sys

[Francis Moreau]

Hello Seewer,

On Wed, Apr 16, 2008 at 9:49 AM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>
>  Correct. Though be really careful which geometry you are requesting:
>
>  root@local:/# sfdisk -g /dev/sda
>  /dev/sda: 7296 cylinders, 255 heads, 63 sectors/track
>  root@local:/# sfdisk -G /dev/sda
>  /dev/sda: 116280 cylinders, 16 heads, 63 sectors/track
>
>  The first one is the kernels idea of a disks geometry which is probably as
> often correct as it's just plain wrong,

Sorry but I don't understand, what do you mean ?

>  versus the second one which tries to
> guess a disks geometry by looking at the current partition table. Which
> might be just as wrong since its only necessary for bios and/or bootloader.

But what happens if you want to guess the geometry of a disk with no
partition table ? You need to trust the kernel guess but from what I understood
it's just wrong.

thanks
-- 
Francis

Re: Disk geometry from /sys

[Seewer Philippe]

Hi,

Francis Moreau wrote:
> Hello Seewer,
> 
> On Wed, Apr 16, 2008 at 9:49 AM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>>  Correct. Though be really careful which geometry you are requesting:
>>
>>  root@local:/# sfdisk -g /dev/sda
>>  /dev/sda: 7296 cylinders, 255 heads, 63 sectors/track
>>  root@local:/# sfdisk -G /dev/sda
>>  /dev/sda: 116280 cylinders, 16 heads, 63 sectors/track
>>
>>  The first one is the kernels idea of a disks geometry which is probably as
>> often correct as it's just plain wrong,
> 
> Sorry but I don't understand, what do you mean ?
Take the example above. A disk with 255 heads? Not impossible but improbable. Where's the value from?

-The physical disks behind the example is an older laptop IDE disk. 'hdparm -I' shows 16 heads and 63 sectors, which is already an approximated value anyway. See Dick Johnson's post about that.

-The module handling the drive is 'ata_piix', the newer Driver from the SATA/PATA tree, which presents all drives (*ATA) to the rest of the system through the scsi sublayer.

-The final "getter" geometry code in the scsi sublayer (scsicam_bios_param in scsicam.c):

        /* if something went wrong, then apparently we have to return
           a geometry with more than 1024 cylinders */
        if (ret || ip[0] > 255 || ip[1] > 63) {
                if ((capacity >> 11) > 65534) {
                        ip[0] = 255;
                        ip[1] = 63;
                } else {
                        ip[0] = 64;
                        ip[1] = 32;
                }

                if (capacity > 65535*63*255)
                        ip[2] = 65535;
                else
                        ip[2] = (unsigned long)capacity / (ip[0] * ip[1]);
        }
Read this as ip[0] is heads, ip[1] is sectors and ip[2] is cylinders. Make sense of course, since C/H/S values don't really matter to scsi anyway. So the default return value for the disks we use today is 255/63 for heads and sectors. A fixed constant which most of the time makes sense and works for most bios and bootloaders, but is wrong in the sense that it doesn't represent the actual values printed on the disks back. 

>>  versus the second one which tries to
>> guess a disks geometry by looking at the current partition table. Which
>> might be just as wrong since its only necessary for bios and/or bootloader.
> 
> But what happens if you want to guess the geometry of a disk with no
> partition table ? You need to trust the kernel guess but from what I understood
> it's just wrong.
Assuming H/S as 255/63 and calculating C from the disks capaticy is quite safe. Except for a few weird use cases like using old OS's and os-installers that still trust the BIOS.
Depending on the type of disks you work with 'hdparm -I' works well too. Otherwise there's always CONFIG_EDD ('BIOS Enhanced Disk Drive calls determine boot disk') which exports BIOS geometry values to sysfs for the current default boot disk.

Hope this helps
Philippe

Re: Disk geometry from /sys

[Mark Lord]

Seewer Philippe wrote:
> Hi,
> 
> Francis Moreau wrote:
>> Hello Seewer,
>>
>> On Wed, Apr 16, 2008 at 9:49 AM, Seewer Philippe 
>> <philippe.seewer@bfh.ch> wrote:
>>>  Correct. Though be really careful which geometry you are requesting:
>>>
>>>  root@local:/# sfdisk -g /dev/sda
>>>  /dev/sda: 7296 cylinders, 255 heads, 63 sectors/track
>>>  root@local:/# sfdisk -G /dev/sda
>>>  /dev/sda: 116280 cylinders, 16 heads, 63 sectors/track
>>>
>>>  The first one is the kernels idea of a disks geometry which is 
>>> probably as
>>> often correct as it's just plain wrong,
>>
>> Sorry but I don't understand, what do you mean ?
> Take the example above. A disk with 255 heads? Not impossible but 
> improbable. Where's the value from?
> 
> -The physical disks behind the example is an older laptop IDE disk. 
> 'hdparm -I' shows 16 heads and 63 sectors, which is already an 
> approximated value anyway. See Dick Johnson's post about that.
..

That can sound a bit misleading.  The complete story, for ATA/SATA drives,
is that the disk has two geometries:  an internal physical one, with a 
fixed number of heads and cylinders, but variable sectors/track
(which normally varies by cylinder zone).

Software *never* sees or knows about that geometry, so ignore it.

The second geometry, is the one that the drive reports to software
as its "native" geometry.  This is what you see from "hdparm -I"
and friends, and this geometry is what has to be used by software
when using cylinder/head/sector (CHS) addressing for I/O operations.
The hardware interface has a limit of 4-bits for the head value,
so the maximum number of heads can never be more than 16.

Nobody uses CHS addressing for I/O operations, at least not on
any hardware newer than at least ten years old, so this geometry
is also unimportant for most uses.

That's what the drive knows about.

Software, for compatibility with the MS-DOS partition table scheme,
sometimes uses a "logical" geometry, where we "pretend" that a drive
can have up to 255 heads, which then allows more of the disk to be
described within the limitations of the partition table data layout.
That's where one frequently sees "255 heads", even though the drive
underneath uses 16 at the interface level, and probably as only 2
or 4 real heads inside the shell.

Cheers
 

Re: Disk geometry from /sys

[Seewer Philippe]

Mark Lord wrote:
> That can sound a bit misleading.  The complete story, for ATA/SATA drives,
> is that the disk has two geometries:  an internal physical one, with a 
> fixed number of heads and cylinders, but variable sectors/track
> (which normally varies by cylinder zone).
> 
> Software *never* sees or knows about that geometry, so ignore it.
> 
> The second geometry, is the one that the drive reports to software
> as its "native" geometry.  This is what you see from "hdparm -I"
> and friends, and this geometry is what has to be used by software
> when using cylinder/head/sector (CHS) addressing for I/O operations.
> The hardware interface has a limit of 4-bits for the head value,
> so the maximum number of heads can never be more than 16.
> 
> Nobody uses CHS addressing for I/O operations, at least not on
> any hardware newer than at least ten years old, so this geometry
> is also unimportant for most uses.
> 
> That's what the drive knows about.
> 
> Software, for compatibility with the MS-DOS partition table scheme,
> sometimes uses a "logical" geometry, where we "pretend" that a drive
> can have up to 255 heads, which then allows more of the disk to be
> described within the limitations of the partition table data layout.
> That's where one frequently sees "255 heads", even though the drive
> underneath uses 16 at the interface level, and probably as only 2
> or 4 real heads inside the shell.

Aye. Though I prefer the term virtual geometry. But thats cosmetics. 
Sorry for beeing unclear, and many thanks for untangling my post.

If anyones interested in even more Details about C/H/S adressing and so 
on, there's a very good document about that to be found here:
http://www.mossywell.com/boot-sequence/

Re: Disk geometry from /sys

[Francis Moreau]

On Fri, Apr 18, 2008 at 3:37 PM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>
>  Mark Lord wrote:
>
> > That can sound a bit misleading.  The complete story, for ATA/SATA drives,
> > is that the disk has two geometries:  an internal physical one, with a
> fixed number of heads and cylinders, but variable sectors/track
> > (which normally varies by cylinder zone).
> >
> > Software *never* sees or knows about that geometry, so ignore it.
> >
> > The second geometry, is the one that the drive reports to software
> > as its "native" geometry.  This is what you see from "hdparm -I"
> > and friends, and this geometry is what has to be used by software
> > when using cylinder/head/sector (CHS) addressing for I/O operations.
> > The hardware interface has a limit of 4-bits for the head value,
> > so the maximum number of heads can never be more than 16.
> >
> > Nobody uses CHS addressing for I/O operations, at least not on
> > any hardware newer than at least ten years old, so this geometry
> > is also unimportant for most uses.
> >
> > That's what the drive knows about.
> >
> > Software, for compatibility with the MS-DOS partition table scheme,
> > sometimes uses a "logical" geometry, where we "pretend" that a drive
> > can have up to 255 heads, which then allows more of the disk to be
> > described within the limitations of the partition table data layout.
> > That's where one frequently sees "255 heads", even though the drive
> > underneath uses 16 at the interface level, and probably as only 2
> > or 4 real heads inside the shell.
> >
>
>  Aye. Though I prefer the term virtual geometry. But thats cosmetics. Sorry
> for beeing unclear, and many thanks for untangling my post.
>
>  If anyones interested in even more Details about C/H/S adressing and so on,
> there's a very good document about that to be found here:
>  http://www.mossywell.com/boot-sequence/
>

unfortunately this link doesn't work for now...

-- 
Francis

Re: Disk geometry from /sys

[Seewer Philippe]

Francis Moreau wrote:
[snip]
>>  If anyones interested in even more Details about C/H/S adressing and so on,
>> there's a very good document about that to be found here:
>>  http://www.mossywell.com/boot-sequence/
>>
> 
> unfortunately this link doesn't work for now...
Google has it cached:
http://209.85.135.104/search?q=cache:www.mossywell.com/boot-sequence/

Re: Disk geometry from /sys

[Francis Moreau]

On Wed, Apr 23, 2008 at 8:44 AM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
> Francis Moreau wrote:
>  [snip]
>
>
> >
> > >  If anyones interested in even more Details about C/H/S adressing and so
> on,
> > > there's a very good document about that to be found here:
> > >  http://www.mossywell.com/boot-sequence/
> > >
> > >
> >
> > unfortunately this link doesn't work for now...
> >
>  Google has it cached:
>  http://209.85.135.104/search?q=cache:www.mossywell.com/boot-sequence/
>

It definitely looks very interesting, I'll take the time to read it
and think more about it.

Thanks a lot !
-- 
Francis

Re: Disk geometry from /sys

[Francis Moreau]

Hello Mark

On Fri, Apr 18, 2008 at 3:22 PM, Mark Lord <lkml@rtr.ca> wrote:
>  That can sound a bit misleading.  The complete story, for ATA/SATA drives,
>  is that the disk has two geometries:  an internal physical one, with a
> fixed number of heads and cylinders, but variable sectors/track
>  (which normally varies by cylinder zone).
>
>  Software *never* sees or knows about that geometry, so ignore it.
>
>  The second geometry, is the one that the drive reports to software
>  as its "native" geometry.  This is what you see from "hdparm -I"
>  and friends, and this geometry is what has to be used by software
>  when using cylinder/head/sector (CHS) addressing for I/O operations.
>  The hardware interface has a limit of 4-bits for the head value,
>  so the maximum number of heads can never be more than 16.
>
>  Nobody uses CHS addressing for I/O operations, at least not on
>  any hardware newer than at least ten years old, so this geometry
>  is also unimportant for most uses.
>

Is it because IDE drives support several IO operation modes ?

thanks
-- 
Francis

Re: Disk geometry from /sys

[Mark Lord]

Francis Moreau wrote:
> Hello Mark
> 
> On Fri, Apr 18, 2008 at 3:22 PM, Mark Lord <lkml@rtr.ca> wrote:
>>  That can sound a bit misleading.  The complete story, for ATA/SATA drives,
>>  is that the disk has two geometries:  an internal physical one, with a
>> fixed number of heads and cylinders, but variable sectors/track
>>  (which normally varies by cylinder zone).
>>
>>  Software *never* sees or knows about that geometry, so ignore it.
>>
>>  The second geometry, is the one that the drive reports to software
>>  as its "native" geometry.  This is what you see from "hdparm -I"
>>  and friends, and this geometry is what has to be used by software
>>  when using cylinder/head/sector (CHS) addressing for I/O operations.
>>  The hardware interface has a limit of 4-bits for the head value,
>>  so the maximum number of heads can never be more than 16.
>>
>>  Nobody uses CHS addressing for I/O operations, at least not on
>>  any hardware newer than at least ten years old, so this geometry
>>  is also unimportant for most uses.
>>
> 
> Is it because IDE drives support several IO operation modes ?
..

The earliest IDE drives for Compaq used only CHS sector addressing mode.

Within four years, though, all new drives had support for the more 
sensible linear block addressing (LBA) mode, as well.

LBA has been mandatory in new drives since the early 1990s,
so there's really no point to CHS addressing any more,
except when fiddling with MS-DOS style partition tables
(which have both CHS and LBA values stored inside).

Cheers

Re: Disk geometry from /sys

[Seewer Philippe]

Mark Lord wrote:
[snip]
> The earliest IDE drives for Compaq used only CHS sector addressing mode.
> 
> Within four years, though, all new drives had support for the more 
> sensible linear block addressing (LBA) mode, as well.
> 
> LBA has been mandatory in new drives since the early 1990s,
> so there's really no point to CHS addressing any more,
> except when fiddling with MS-DOS style partition tables
> (which have both CHS and LBA values stored inside).

Sorry, can't resist that quip here... Many of the well known x86-based 
OS', OS-installers and even bootloaders from this millenium trusted the 
partition tables c/h/s values to match the bios... causing havoc say 
with PATA drives atached to SATA connectors.

If that weren't the case I guess Linux could have get rid of c/h/s a 
looong time ago. Hmmm... maybe its time?

Re: Disk geometry from /sys

[Francis Moreau]

On Wed, Apr 23, 2008 at 12:44 AM, Mark Lord <lkml@rtr.ca> wrote:
> > On Fri, Apr 18, 2008 at 3:22 PM, Mark Lord <lkml@rtr.ca> wrote:
> >
> > >  That can sound a bit misleading.  The complete story, for ATA/SATA
> drives,
> > >  is that the disk has two geometries:  an internal physical one, with a
> > > fixed number of heads and cylinders, but variable sectors/track
> > >  (which normally varies by cylinder zone).
> > >
> > >  Software *never* sees or knows about that geometry, so ignore it.
> > >
> > >  The second geometry, is the one that the drive reports to software
> > >  as its "native" geometry.  This is what you see from "hdparm -I"
> > >  and friends, and this geometry is what has to be used by software
> > >  when using cylinder/head/sector (CHS) addressing for I/O operations.
> > >  The hardware interface has a limit of 4-bits for the head value,
> > >  so the maximum number of heads can never be more than 16.
> > >
> > >  Nobody uses CHS addressing for I/O operations, at least not on
> > >  any hardware newer than at least ten years old, so this geometry
> > >  is also unimportant for most uses.
> > >
> > >
> >
> > Is it because IDE drives support several IO operation modes ?
> >
>  ..
>
>  The earliest IDE drives for Compaq used only CHS sector addressing mode.
>
>  Within four years, though, all new drives had support for the more sensible
> linear block addressing (LBA) mode, as well.
>

My last question I promise ;)

If I'd like to take a look in the kernel code to see where the kernel
translates an offset
provided by sys_read into a LBA or CHS address, where should I go ?
drivers/block ?

Thanks !
-- 
Francis

Re: Disk geometry from /sys

[Seewer Philippe]

Francis Moreau wrote:
[snip]
> If I'd like to take a look in the kernel code to see where the kernel
> translates an offset
> provided by sys_read into a LBA or CHS address, where should I go ?
> drivers/block ?
No just /block

from Documentation/block/biodoc.txt

[quote]
Drivers no longer have to map a {partition, sector offset} into the
correct absolute location anymore, this is done by the block layer, so
where a driver received a request ala this before:

         rq->rq_dev = mk_kdev(3, 5);     /* /dev/hda5 */
         rq->sector = 0;                 /* first sector on hda5 */

   it will now see

         rq->rq_dev = mk_kdev(3, 0);     /* /dev/hda */
         rq->sector = 123128;            /* offset from start of disk */
[/quote]


/drivers/block is block-device drivers not the block layer itself.

Re: Disk geometry from /sys

[Mark Lord]

Francis Moreau wrote:
> My last question I promise ;)
> 
> If I'd like to take a look in the kernel code to see where the kernel
> translates an offset
> provided by sys_read into a LBA or CHS address, where should I go ?
..

Two places.  drivers/ide/ide-disk.c :: __ide_do_rw_disk()
and drivers/ata/libata-core.c :: ata_build_rw_tf().

Cheers

Re: Disk geometry from /sys

[Francis Moreau]

Hi Seewer,

Sorry for being late.

On Thu, Apr 17, 2008 at 4:49 PM, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>  Take the example above. A disk with 255 heads? Not impossible but
> improbable. Where's the value from?
>
>  -The physical disks behind the example is an older laptop IDE disk. 'hdparm
> -I' shows 16 heads and 63 sectors, which is already an approximated value
> anyway. See Dick Johnson's post about that.
>
>  -The module handling the drive is 'ata_piix', the newer Driver from the
> SATA/PATA tree, which presents all drives (*ATA) to the rest of the system
> through the scsi sublayer.
>
>  -The final "getter" geometry code in the scsi sublayer (scsicam_bios_param
> in scsicam.c):
>
>        /* if something went wrong, then apparently we have to return
>           a geometry with more than 1024 cylinders */
>        if (ret || ip[0] > 255 || ip[1] > 63) {
>                if ((capacity >> 11) > 65534) {
>                        ip[0] = 255;
>                        ip[1] = 63;
>                } else {
>                        ip[0] = 64;
>                        ip[1] = 32;
>                }
>
>                if (capacity > 65535*63*255)
>                        ip[2] = 65535;
>                else
>                        ip[2] = (unsigned long)capacity / (ip[0] * ip[1]);
>        }
>  Read this as ip[0] is heads, ip[1] is sectors and ip[2] is cylinders. Make
> sense of course, since C/H/S values don't really matter to scsi anyway. So

Just out of curiosity, what does scsi use for addressing IO operations ?

> the default return value for the disks we use today is 255/63 for heads and
> sectors. A fixed constant which most of the time makes sense and works for
> most bios and bootloaders, but is wrong in the sense that it doesn't
> represent the actual values printed on the disks back.
>
> >
> > >  versus the second one which tries to
> > > guess a disks geometry by looking at the current partition table. Which
> > > might be just as wrong since its only necessary for bios and/or
> bootloader.
> > >
> >
> > But what happens if you want to guess the geometry of a disk with no
> > partition table ? You need to trust the kernel guess but from what I
> understood
> > it's just wrong.
> >
>  Assuming H/S as 255/63 and calculating C from the disks capaticy is quite
> safe. Except for a few weird use cases like using old OS's and os-installers
> that still trust the BIOS.
>  Depending on the type of disks you work with 'hdparm -I' works well too.
> Otherwise there's always CONFIG_EDD ('BIOS Enhanced Disk Drive calls
> determine boot disk') which exports BIOS geometry values to sysfs for the
> current default boot disk.
>
>  Hope this helps

Thanks a lot for your time.
-- 
Francis

Re: Disk geometry from /sys

[Seewer Philippe]

Francis Moreau wrote:
[snip]
> Just out of curiosity, what does scsi use for addressing IO operations ?
I'm quoting from http://www.mossywell.com/boot-sequence/
[quote]
LBA has been around since around 1981. It is the method used to access 
SCSI drives. However, in the mid-1990s IDE disks finally caught up with 
SCSI and started to use LBA as well.
[/quote]

Further Information is provided by wikipedia as well:
http://en.wikipedia.org/wiki/SCSI
http://en.wikipedia.org/wiki/Logical_block_addressing

Have fun!
Philippe Seewer