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/