It reminds me of how video game companies sometimes create whole virtual file systems in gigabyte+ blobs to deal with the limits of OS file systems. They're probably less useful in 2021 with SSDs becoming the norm. With hard drives, the thousands of files a game uses would end up in little fragments all over the platters and lead to horrible latency and head thrashing.

At least hard drives still have decent seek times. Load time optimization for consoles with optical drives was another league: a single seek across the disk could lead to waiting a second longer on the loading screen.

Crash Bandicoot solved this problem by writing the level data in a streaming fashion, so that the CD-ROM would never have to seek while playing through a level.

Of course, the CD-ROM only spins in one direction however. Crash Bandicoot programmers solved this issue by making it impossible to run backwards in the game.

The game was basically one dimensional on purpose: you can only run forward, and never backwards, to optimize the CD-ROM bandwidth. Still, the game was groundbreaking, the gameplay and characters fresh. Its an incredible technical achievement, to the point where most people didn't even realize that running backwards was a technical hurdle they felt like not solving.

> Of course, the CD-ROM only spins in one direction however. Crash Bandicoot programmers solved this issue by making it impossible to run backwards in the game.

I've been playing crash since I was a kid, and I never thought about why you couldn't run backwards. What a brilliant solution.

> With hard drives, the thousands of files a game uses would end up in little fragments all over the platters and lead to horrible latency and head thrashing.

I remember the PC game "Riven" which came on several CDs. The game would often pause and ask you to insert another CD to continue.

From the article:

"There are existing distributed file systems for the cloud as well as off-the-shelf FUSE modules for S3. We chose to enhance MezzFS instead of using these other solutions because the cloud storage system where packager stores its output is a custom object store service built on top of S3 with additional security features. Doing so has the added advantage of being able to design and tune the enhancement to suit the requirements of packager and our other encoding applications."

It says a lot without saying anything meaningful.

Netflix doesn't use S3 as-is but with a wrapper on top which means they couldn't use off-the-shelf solutions.

aka ...the cloud storage system where packager stores its output is a custom object store service built on top of S3 with additional security features.

Little details like being able to assume a single writer makes such a thing dramatically simpler than something (near-)POSIX such as Ceph.

Think of it more as a streaming chunked uploader where the API is a FUSE mount, for legacy interop.