From: Mark Lord <lkml@rtr.ca>
To: Jens Axboe <axboe@kernel.dk>, Jeff Garzik <jgarzik@pobox.com>,
Tejun Heo <htejun@gmail.com>, Greg KH <gregkh@suse.de>
Cc: Linus Torvalds <torvalds@osdl.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: What to do about the 2TB limit on HDIO_GETGEO ?
Date: Tue, 25 Mar 2008 00:02:10 -0400 [thread overview]
Message-ID: <47E87942.2020409@rtr.ca> (raw)
In-Reply-To: <47E875AD.1000901@rtr.ca>
(resending .. forgot to copy the lists originally)
We have a problem coming down the pipeline.
Practically all utilities that care about it,
use ioctl(fd, HDIO_GETGEO) to determine the starting
sector offset of a hard disk partition.
SCSI, libata, IDE, USB, Firewire.. you name it.
The return value uses "unsigned long",
which on a 32-bit system limits drive offsets to 2TB.
There will be single drives exceeding this limit within
the next 12 months or less, and we already have RAID arrays
that exceed 2TB.
So.. what's the replacement for HDIO_GETGEO on 32-bits ?
One candidate might seem to be the existing /sys/block/dev/partition/start
which I expect is already 64-bit friendly.
But this requires about 150 lines of somewhat complex C code to access,
using only the dev_t (from stat(2) on a file) as a starting point,
or less if one relies upon the udev device name matching the sysfs device name.
Is it time now for HDIO_GETGEO64 to make an appearance?
Similar to how the existing BLKGETSIZE64 is supplanting BLKGETSIZE ?
??
next parent reply other threads:[~2008-03-25 4:02 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <47E875AD.1000901@rtr.ca>
2008-03-25 4:02 ` Mark Lord [this message]
2008-03-25 4:19 ` What to do about the 2TB limit on HDIO_GETGEO ? Andrew Morton
2008-03-25 5:13 ` H. Peter Anvin
2008-03-25 13:37 ` Mark Lord
2008-03-25 13:55 ` H. Peter Anvin
2008-03-25 17:37 ` Mark Lord
2008-03-25 19:25 ` Greg KH
2008-03-25 19:34 ` Randy Dunlap
2008-03-25 20:36 ` H. Peter Anvin
2008-03-25 21:20 ` Greg KH
2008-03-25 21:26 ` H. Peter Anvin
2008-03-25 23:00 ` Greg KH
2008-03-25 23:05 ` H. Peter Anvin
2008-03-25 23:22 ` Greg KH
2008-03-27 19:05 ` Matthew Wilcox
2008-03-26 0:34 ` Mark Lord
2008-03-26 0:54 ` Tejun Heo
2008-03-26 3:38 ` Greg KH
2008-03-26 4:24 ` Tejun Heo
2008-03-26 6:04 ` H. Peter Anvin
2008-03-27 19:29 ` Kay Sievers
2008-03-27 19:38 ` H. Peter Anvin
2008-04-11 23:25 ` Dan Williams
2008-04-15 7:18 ` Andrew Morton
2008-04-15 13:47 ` Mark Lord
2008-04-15 14:20 ` James Bottomley
2008-04-15 18:16 ` H. Peter Anvin
2008-04-15 23:43 ` Dan Williams
2008-04-16 20:55 ` patch sysfs-add-sys-dev-char-block-to-lookup-sysfs-path-by-major-minor.patch added to gregkh-2.6 tree gregkh
2008-03-27 18:51 ` What to do about the 2TB limit on HDIO_GETGEO ? Kay Sievers
2008-03-27 18:55 ` H. Peter Anvin
2008-03-27 19:03 ` Kay Sievers
2008-03-25 15:17 ` James Bottomley
2008-03-25 17:31 ` Mark Lord
2008-03-25 19:32 ` James Bottomley
2008-03-25 17:45 ` Greg Freemyer
2008-03-25 17:52 ` Randy Dunlap
2008-03-25 18:09 ` Matthew Wilcox
2008-03-26 9:58 ` Boaz Harrosh
2008-03-30 4:28 ` Matt Domsch
[not found] ` <alpine.LFD.1.00.0803242254020.2775@woody.linux-foundation.org>
2008-03-25 13:34 ` Mark Lord
2008-03-25 13:51 ` Greg Freemyer
2008-03-25 14:31 ` Ric Wheeler
2008-03-25 15:25 ` Andrew Paprocki
2008-03-25 15:34 ` Matthew Wilcox
2008-03-25 15:48 ` Ric Wheeler
2008-03-25 16:47 ` Theodore Tso
2008-03-25 20:51 ` Theodore Tso
[not found] <abhxL-xC-7@gated-at.bofh.it>
[not found] ` <abhRd-1bf-15@gated-at.bofh.it>
[not found] ` <ablib-2zv-65@gated-at.bofh.it>
[not found] ` <abn0B-735-35@gated-at.bofh.it>
[not found] ` <abna7-7jK-3@gated-at.bofh.it>
[not found] ` <abo6b-11J-9@gated-at.bofh.it>
[not found] ` <aboSP-2Wf-29@gated-at.bofh.it>
[not found] ` <aboSP-2Wf-27@gated-at.bofh.it>
[not found] ` <abqrq-6eX-29@gated-at.bofh.it>
[not found] ` <abqrq-6eX-27@gated-at.bofh.it>
[not found] ` <abqKM-6Ka-13@gated-at.bofh.it>
2008-03-26 11:30 ` Bodo Eggert
[not found] ` <E1JeTq5-00018y-MO@be1.7eggert.dyndns.org>
2008-03-27 3:52 ` Greg KH
2008-03-27 4:57 ` H. Peter Anvin
2008-03-27 14:45 ` Mark Lord
2008-03-27 15:15 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E87942.2020409@rtr.ca \
--to=lkml@rtr.ca \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=gregkh@suse.de \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).