login
Search
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 --
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 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. ...
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 --
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
--
Just use LBA. Both lilo and grub can, in which case they no longer care about the geometry at all. -- Len Sorensen --
Hello, On Wed, Apr 9, 2008 at 11:28 PM, Lennart Sorensen or to create a new entry in /sys: /sys/block/sda/geometry/heads 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 --
$ DEV=/dev/sda
$ GEOM="`/sbin/hdparm -g $DEV | awk '{print $3}'`"
$ echo $GEOM
19457/255/63
$
--
Hi 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 --
.. 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.. --
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 ...
Hi, On Thu, Apr 10, 2008 at 2:22 PM, linux-os (Dick Johnson) 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 --
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 --
Hi Francis, 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, + ...
Hi Seewer, Yes but I'm doing userspace stuff and that's the reason I was asking for the 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 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 --
Hi, 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 --
Hello Seewer, 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 --
Hi,
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]);
}
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
--
.. 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 --
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/ --
Francis Moreau wrote: 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 --
.. 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 --
Mark Lord wrote: 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? --
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 --
Francis Moreau wrote:
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.
--
.. Two places. drivers/ide/ide-disk.c :: __ide_do_rw_disk() and drivers/ata/libata-core.c :: ata_build_rw_tf(). Cheers --
Francis Moreau wrote: 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 --
