linux-kernel - Re: What to do about the 2TB limit on HDIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Mar 2008 09:34:16 -0400
From:	Mark Lord <lkml@....ca>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Jeff Garzik <jgarzik@...ox.com>,
	Tejun Heo <htejun@...il.com>, Greg KH l <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ?

Linus Torvalds wrote:
> 
> On Mon, 24 Mar 2008, Mark Lord wrote:
>> The return value uses "unsigned long",
>> which on a 32-bit system limits drive offsets to 2TB.
> 
> One relevant question is: does anybody seriously care about the 
> combination of "32 bit" and "huge modern drives" any more?
> 
> Sure, we can add a 64-bit version that ends up being used only on 32-bit 
> systems, but quite frankly, I think the solution here is to just ignore 
> the issue and see if anybody really even cares.
> 
> Because quite frankly, the kind of people who buy modern 2TB drives 
> generally don't then couple them to CPU's that are five+ years old.
..

Yeah.  Except Dell will undoubtedly have them in desktops
within 2 years, and tons of people (myself included) still use
32-bit (K)Ubuntu on our systems, simply for the better binary 
compatibility that it is perceived to give with things like
browser plugins and stuff.

Using sysfs interfaces might be a good alternative,
if they were easier to use, but drives are not directly
accessible there using the dev_t value from stat(2).

Instead, software has to search everything inside /sys/block/
looking for a "dev" file whose contents match,
rather than just trying to access something like this:

   /sys/block/8:1/start
or
   /sys/block/majors/8/minors/1/start

Or any one of a number of similar ways to arrange it.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/