creiht

It is probably worth noting that most of the listed storage systems (including S3) are designed to scale not only in hard drives, but horizontally across many servers in a distributed system. They really are not optimized for a single storage node use case. There are also other things to consider that can limit performance, like what does the storage back plane look like for those 80 HDDs, and how much throughput can you effectively push through that. Then there is the network connectivity that will also be a limiting factor.

I rarely comment on HN, but I appreciate these moments that remind me that the internet can still be a beautiful place. Cliff, watching the Nova special (and later reading the book), was very formative in deciding to pursue a CS degree, and it has been a blessing to see your humble replies here. Keep doing what you do, and one day I will be able to mark off a bucket list item of being able to stop by and purchase a Klein bottle in person!

I've been super happy with mine as well. It is a great balance of flexibility and usability. I had a MicroTik prior which worked well, but I was just tired of having to re-learn networking chops to make any changes. The Synology really has been a breath of fresh air, and have had no problems with it over the past year.

Late to the party, but one does not simply store 10PB of data :)

The short story is, ignore most of the advice, poach^H^H^H^H^Hhire someone who has done this, and leverage their expertise. There is no armchair quarterbacking infrastructure at this scale.

You really needed 16MB of RAM for it to run well and that cost an arm and a leg back then. I remember scraping together enough to upgrade to 8MB just to get it running reasonably without swapping constantly.

And the mailing list announcement: http://lists.openstack.org/pipermail/openstack-dev/2015-Apri...

We use it quite extensively for Rackspace's Cloudfiles (Openstack Swift). I discuss it a bit in this talk: https://www.youtube.com/watch?v=YxnFUQHIwNs

Ahh, sorry. Yes, there are limitations around edge purging (how many you can do at a time, and how long it takes for the purges to occur). All of these are also dependent on parameters defined by Akamai. I'll pass the feedback on to our product team as we try to make that experience better. Thanks!

Hi, I work on the cloudfiles team. I'm assuming that you are talking about the TTL setting for the container that is exposed to the CDN. Currently, the minimum that it can be is 15 minutes. We partner with Akamai for the CDN functionality, so while we get all the benefits of the Akamai network, we also have to work within the parameters of their systems. Would you mind sharing more about your use case for needing shorter TTLs?