linux-kernel - Re: How to handle >16TB devices on 32 bit hosts ??

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-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20090718043155.GI4231@webber.adilger.int>
Date:	Sat, 18 Jul 2009 00:31:55 -0400
From:	Andreas Dilger <adilger@....com>
To:	Neil Brown <neilb@...e.de>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-raid@...r.kernel.org, dm-devel@...hat.com
Subject: Re: How to handle >16TB devices on 32 bit hosts ??

On Jul 18, 2009  10:08 +1000, Neil Brown wrote:
>  It has recently come to by attention that Linux on a 32 bit host does
>  not handle devices beyond 16TB particularly well.
> 
>  In particular, any access that goes through the page cache for the
>  block device is limited to a pgoff_t number of pages.
>  As pgoff_t is "unsigned long" and hence 32bit, and as page size is
>  4096, this comes to 16TB total.
:
:
>  I suppose we could add a CONFIG option to make pgoff_t be 
>  "unsigned long long".  Would the cost/benefit of that be acceptable?

I think the point is that for those people who want to use > 16TB
devices on 32-bit platforms (e.g. embedded/appliance systems) the
choice is between "completely non-functional" and "uses a bit more
memory per page", and the answer is pretty obvious.

For users who don't want to support this, they don't have to (just
like CONFIG_LBD or whatever), and for 64-bit systems it is irrelevant.
I think years ago we had the idea that it would be 64-bit everywhere
by now, and while that is true for many systems, embedded/appliance
systems will probably continue to be 32-bit for as long as they can.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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/