On November 28, 2001 04:38 am, Linus Torvalds wrote:
> We will probably _not_ get 64-bit page index numbers, though. I don't want
> to make the page structure bigger/slower for very little gain. So the page
> cache is probably going to be limited to about 44 bits (45+ if people
> start doing large pages, which is probably worth it). So there would still
> be partition/file limits on the order of 16-64 TB in the next few years.
The Ext2+ crowd is actively working on preparing for the world of larger
blocks, so that 64KB blocks will be entirely practical. This will get us to
1/4 Petabyte, still with 32 bit block pointers internally. The main problem
that has to be solved is internal fragmentation.
Going beyond 64KB blocks with mimimal changes is possible too, basically just
working around the 16 bit pointers in directory blocks. However, it's not
clear it's a pressing need.
> (In a longer timeframe, assuming RAM keeps getting cheaper and cheaper,
> and 64-bit computing starts hppening on PC's, a few years down the line we
> can re-visit this - that particular transition is not going to be too
> painful).
>
> And yes, I realize that you can already build big arrays and use LVM etc
> to make them be more than 16TB. I just do not think it's a problem yet,
> and I'd rather cater to "normal" people than to peopel who can't bother
> to partition their data at all.
Right, there's still a lot more scalability to be squeezed out of good old 32
bits. If we do run out of something it's likely to be the 32 bits of inodes,
after all, who can get by on a mere 4 billion files these days?
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org 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 : Fri Nov 30 2001 - 21:00:38 EST