3 ms·
...As data you can access as a filesystem. S3 is great, but pretending it's a filesystem is going to get you awful performance. As I said, our data is not lost
by jespern 17y ago
...As data you can access as a filesystem. S3 is great, but pretending it's a filesystem is going to get you awful performance.
As I said, our data is not lost, we have snapshots and backups, it's sitting right there on the mount, we're just not getting any sort of acceptable throughput. New instances does not fix the problem.
Ironically, we were looking into having S3 as the backend for our data, for scalability/redundancy purposes, but this pretty much puts a stop to that.
- gfodor 17y agoWhen we had the problem we fixed it by snapshotting the screwed up volume, and creating a new volume from that snap. Did you guys try this?
- jespern 17y ago(I don't know why I can't reply to the post below, so I'll reply to myself): Yes, we did try this, and it produced the same problem.
- keefe 17y agoOh, I wasn't suggesting pretending it's a file system - I had been thinking of a place to dump the data for backups, thinking fresh instances + fresh EBS would solve the problem. I think you answered this already in the other post - that you booted a new instance and a new EBS with some backup and the problem remained?? This seems like such a horrendous failure on AWS' part, unless it has something to do with how you are accessing the EBS (too many connections or something). I could understand if a given EBS fails, but if you can restore the data from an independent backup and spin back up with new instances and new EBS this indicates a very concerning systemic problem in EBS!