Re: What to do about the 2TB limit on HDIO_GETGEO ?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2008-03-25 at 13:31 -0400, Mark Lord wrote:
> James Bottomley wrote:
> > On Tue, 2008-03-25 at 00:02 -0400, Mark Lord wrote:
> >..
> >> Practically all utilities that care about it,
> >> use ioctl(fd, HDIO_GETGEO) to determine the starting
> >> sector offset of a hard disk partition.
> ..
> > Perhaps I've missed something, but surely geometry doesn't make sense on
> > a >2TB drive does it?  The only reason we use it on modern disks (which
> > usually make it up specially for us) is that the DOS partition scheme
> > requires it.  Once we're over 2TB, isn't it impossible to use DOS
> > partitions (well, OK, unless you increase the sector size, but that's
> > only delaying the inevitable), so we can just go with a proper disk
> > labelling scheme and use BLKGETSIZE64 all the time.
> ..
> 
> I haven't thought much about problems with the virtual geometry,
> because, as you say, we really don't care about it for the most part.
> We use LBA values from the partition tables rather than CHS.
> I suppose those also likely to be 32-bit limited.
> 
> The "partition offset", or "starting sector" is the important
> bit of information for most things.  And that's currently available
> from HDIO_GETGEO, and from /sys/block/XXX/XXXn/start, if sysfs is mounted.
> 
> We just need an easy way to get it, given a dev_t from stat(2).
> Currently there isn't an easy way, and HDIO_GETGEO returns
> only 32-bits on a 32-bit system.

But I think where this is leading is that you've been using the geometry
call, but all you really want to know is the actual partition start in
sector units, so a new BLKGETPARTSTART (or something) ioctl that was
designed to return a u64 would work for you?  That sounds reasonable to
me; so not a HDIO_GETGEO64 which gets us into trouble with geometries,
but a simple ioctl that gives you exactly what you're looking for.

James