Daniel Phillips wrote:
>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.
>
This is a bad idea for general purpose usage patterns. The problem is
that if you cure the internal fragmentation problem like reiserfs did,
you are still going to be left with a memory bandwidth consumption that
is proportional to the size of nodes, because inserting an 8 byte item
is likely to cause a shift of contents proportional to node size.
We need to go to 64 bit blocknumbers and 64 bit inode numbers. If we
are not going to do this, well, I really need to change the design of
Reiser4, as I was just assuming it would be done. We get some nice
simplicities out of never reusing objectids (with 64 bits, you never run
out of them, the math for what it takes to run out of them assuming you
use a trillion a second is a bit amusing.)
I recommend the use of 64 bits for inode numbers and blocknumbers plus
the use of compression (effective for filesystems small enough to not
use all 64 bits) for those who dislike the byte wastage.
Hans
-
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