Yeah, one of my main debugging tasks right now is primarily limited by my SSD write speed. Instruction-level traces take 9gb at minimum, any more significant work takes quite a lot more.

How are you generating the instruction traces? What format are you writing them to on disk?

Ollydbg run traces and in a plain text format. I'm constrained by my target application only working on older versions of windows, so I can't easily insert a compression step in the log generation or switch to a more compact binary representation.

(I'm currently looking into solutions like a custom filesystem driver, running a second VM and using internal networking to stream to a FUSE filesystem, or possibly even hooking the filesystem access of my debugger and inserting a compression step into WriteFile() calls)

As its transfer speed yes I do.

I don't have to move 10GB+ files to know if my network is 10MB/100MB/1000MB/10G0B. The speed it transfers is representative of my network speed be that file 4k, 10MB, or 100GB.

The same is true for all transfer speeds.

:.:.:

Also yes there are diminishing returns with information requests, acks, etc.

"git grep" on a large source tree. (Or, for that matter, "repo grep" on a whole family of git repositories.)

Upgrading to Mavericks comes to mind.

Try working with map data, where having layers that consumes tens of GB, and having hundreds of layers, is not that unusual. Load that into a database, and watch the size blow up even further thanks to indexes etc.

There are plenty of applications that are still disk IO constrained at those speeds.

Uncompressed 16-bit 16K for mastering high-quality 4K content? It is thought 8K will be the final TV resolution - for that you'd need 32K for a good quality output - I guess even current DDR3 would be too slow, not mentioning SSDs.

Ad-hoc connecting new Macs over Thunderbolt 2 at 20Gbits/sec is very nice! My MacBook Pro and Mac Pro share their 1TB SSD drives between each other via TB2.

SVN, some people are still stuck using it....