Subject: Re: [PATCH] remove 2TB block device limit
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Comments: Hyperbole mail buttons accepted, v04.18.
--text follows this line--
>>>>> "Andrew" == Andrew Morton <firstname.lastname@example.org> writes:
Andrew> Peter Chubb wrote:
>> Hi, At present, linux is limited to 2TB filesystems even on 64-bit
>> systems, because there are various places where the block offset on
>> disc are assigned to unsigned or int 32-bit variables.
>> There's a type, sector_t, that's meant to hold offsets in sectors
>> and blocks. It's not used consistently (yet).
>> The patch at
>> As this touches lots of places -- the generic block layer (Andrew?)
>> the IDE code (Martin?) and RAID (Neil?) and minor changes to the
>> scsi I've CCd a few people directly.
Andrew> That would be more Jens and aviro than I.
OK, I'll forward it to them... (And I've added them to the CC list here)
Andrew> My vote would be: just merge the sucker while it still
Andrew> (almost) applies. 2TB is a showstopper for some people in 2.4
Andrew> today. Obviously 2.6 will need 64-bit block numbers.
Yes. But not always, I think --- the overhead on low-end boxes I
think may be prohibitive. It should be a configuration option.
Andrew> The next obstacle will be page cache indices into the blockdev
Andrew> mapping. That's either an 8TB or 16TB limit, depending on
Andrew> signedness correctness.
It's OK at 16TB now. That was the point of the bmap() change.
And if you go to larger pages, or a larger index in the page cache,
you can get even bigger (but I don't think it's necessary just now).
Andrew> One minor point - it is currently not possible to print
Andrew> sector_t's. This code:
Andrew> printk("%lu%s", some_sector, some_string);
Andrew> will work fine with 32-bit sector_t. But with 64-bit sector_t
Currently, sector_t is cast to u64 everywhere it's printed out, and
the format %llu used. I looked at the possibility of usng a PRIsector
macro a la inttypes.h but thought the result incredibly ugly. Mind
you, casts aren't particularly clean
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:13 EST