Live data from Hacker News

Will I ever own a zettaflop?

geohot.github.io

21–30 of 98 posts

Re: Will I ever own a zettaflop?

#21
post #12

Somewhat related, why the creators of Zettabyte File System (ZFS) decided to make it 128 bits (writing in 2004): > Some customers already have datasets on the order of a petabyte, or 2^50 bytes. Thus the 64-bit capacity limit of 2^64 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a deca…

Very interesting, could someone please do the same computation for filling 64 bit storage?

16 million terablocks, or 8 billion terabytes.

Or a third of a billion 24 TB drives, which is one of the larger sizes currently available.

Some random search results say the global hard drive market is around an eighth of a billion units, but of course much of that will be smaller sizes.

So that should be physically realizable today (well, with today's commercial technology), with only a few years of global production.

Re: Will I ever own a zettaflop?

#22

Somewhat related, why the creators of Zettabyte File System (ZFS) decided to make it 128 bits (writing in 2004): > Some customers already have datasets on the order of a petabyte, or 2^50 bytes. Thus the 64-bit capacity limit of 2^64 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a deca…

Single data sets surpassed 2^64 bytes over a decade ago. This creates fun challenges since just the metadata structures can't fit in the RAM of the largest machines we build today.

Virtualization has pushed back the need for a while, but we are going to have to look at pointers larger than 64 bit at some point. It's also not just about the raw size of datasets, but how we get a lot of utility out of various memory mapping tricks, so we consume more address space than the strict minimum required by the dataset. Also if we move up to 128 bit a lot more security mitigations become possible.

Re: Will I ever own a zettaflop?

#24
post #12

Earlier quoted context omitted.

Very interesting, could someone please do the same computation for filling 64 bit storage?

16 million terablocks, or 8 billion terabytes. Or a third of a billion 24 TB drives, which is one of the larger sizes currently available. Some random search results say the global hard drive market is around an eighth of a billion units, but of course much of that will be smaller sizes. So that should be physically realizable today (well, with today's commercial technology), with only a few years of global productio…

> 16 million terablocks, or 8 billion terabytes.

To be clear, the first quote was talking about 2^64 bytes, and you're talking about 2^64 blocks.

Edit: Though confusingly the second part talked about 2^128 blocks.

Also these days I'd assume 4KB blocks instead of 512 bytes.

Re: Will I ever own a zettaflop?

#26

I just want to thank the submitter. This is the type of internet that I really miss. A very smart person who's a good writer, proud of their interests and obsessions.

I disagree. Comes off as an arrogant guy rather than a curious scientist.

What will it take to get this before you die? What are physical limitations to shrink things more and more and to speed things up more and more? He talks about solar, but what are the physical limits and how can we get there?

I think there's interesting physics here, but this sounds like just a rich guy craving more power.

Re: Will I ever own a zettaflop?

#27
post #5

There's no way we're not living in a historical simulation. This is all just such crazy coincidence. Everything is coming together so quickly.

What's a "a historical simulation" and why is it all such a coincidence?

The "simulation argument" to me is ridiculous.

Re: Will I ever own a zettaflop?

#28

Earlier quoted context omitted.

16 million terablocks, or 8 billion terabytes. Or a third of a billion 24 TB drives, which is one of the larger sizes currently available. Some random search results say the global hard drive market is around an eighth of a billion units, but of course much of that will be smaller sizes. So that should be physically realizable today (well, with today's commercial technology), with only a few years of global productio…

> 16 million terablocks, or 8 billion terabytes. To be clear, the first quote was talking about 2^64 bytes, and you're talking about 2^64 blocks. Edit: Though confusingly the second part talked about 2^128 blocks. Also these days I'd assume 4KB blocks instead of 512 bytes.

> To be clear, the first quote was talking about 2^64 bytes

That's 16 exabytes. Wikipedia cites a re:invent video to say that Amazon S3 has "100s of exabytes" in it.

So it not only could theoretically be done, but has been done.

https://en.wikipedia.org/wiki/Amazon_S3

Re: Will I ever own a zettaflop?

#29

Earlier quoted context omitted.

Single data sets surpassed 2^64 bytes over a decade ago. This creates fun challenges since just the metadata structures can't fit in the RAM of the largest machines we build today.

Virtualization has pushed back the need for a while, but we are going to have to look at pointers larger than 64 bit at some point. It's also not just about the raw size of datasets, but how we get a lot of utility out of various memory mapping tricks, so we consume more address space than the strict minimum required by the dataset. Also if we move up to 128 bit a lot more security mitigations become possible.

By virtualization are you referring to virtual memory? We haven't even been able to mmap() the direct-attached storage on some AWS instances for years due to limitations on virtual memory.

With larger virtual memory addresses there is still the issue that the ratio between storage and physical memory in large systems would be so high that cache replacement algorithms don't work for most applications. You can switch to cache admission for locality at scale (strictly better at the limit albeit much more difficult to implement) but that is effectively segmenting the data model into chunks that won't get close to overflowing 64-bit addressing. 128-bit addresses would be convenient but a lot of space is saved by keeping it 64-bit.

Space considerations aside, 128-bit addresses would open up a lot of pointer tagging possibilities e.g. the security features you allude to.

Post reply on HN