We would love to have a way to mount block level storage (like EBS) to linodes, and would pay decent money to have this feature. For example, say we could create a storage device of say 100gigs, and then mount that device to a single or even multiple linodes.

This would be great for load balanced setups, since linodes can read & write files from a centralized source.

The only problem I see, is currently the maximum network link speed on linodes appears to be 100mbps even on the private interface. For this to work, and provide any good performance Linode would need to increase connections to gigabit on the private interface.

I'd probably prefer something less like EBS and more like S3. Very few filesystems handle multiple read/write mounts of the same device, and EBS is known for being somewhat limited in performance and availability. There might be better options nowadays, though, like GlusterFS.

_________________

/* TODO: need to add signature to posts */

Indeed, would love Linode to deal with the complexity and details of settings up FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace), specifically GlusterFS.

How much money? Everybody always wants S3 or EBS-like prices, which may not be practical. Would you be willing to pay the same storage costs as normal Linodes?


Unfortunately, there isn't a "private interface". All traffic goes over the same interface, and it's limited to 50 Mbps outbound by default. You can file a ticket and get it raised if you can justify it. I've never heard of anyone getting their limits set to more than a couple hundred Mbps, though.

_________________
Matt Nordhoff (aka Peng on IRC)

No, nor should they. Even if Linode used the same calibre of hardware as they do in individual linodes (in terms of performance and redundancy), there should be at least some improvement in efficiency due to less wasted space (I'm assuming EBS is dynamically allocated as consumed). But what people want most of all is a more affordable storage option; very fast local storage (what we have now) combined with cheaper and slower networked storage. And I think people envision the S3/EBS/iSCSI/NFS/whatever style storage as this option.



Is there any particular reason that Linode couldn't do different limits based on the packet destination if they had to? Regardless, there's no limit on inbound, which means that you'd at least be able to access the data as fast as the network infrastructure supports.

The highest I've ever seen the limit raised is 150 megabit (in my own case) on a temporary basis (I was migrating data between two linodes). They're very stingy about raising the limit, and I have absolutely no problem with that (limits how much damage a runaway linode can cause to my credit card).

I don't get the point of people wanting Linode to provide an S3 type of solution. If all you need is storage, just use S3 or if needed CloudFront.

I am suggesting a different solution; elastic storage that can be mounted to Linodes as if it were physical disks with LOW LATENCY. Even further, can be mounted to multiple Linodes. Basically the real use case for this is a load balanced setup, where a cluster of Linodes read/write files from a centralized mount point.

My experience with EBS was abysmal from the performance perspective. It is pretty cheap, though. But couldn't you just mount a shared volume over the private network? Or use DRBD, which provides real redundancy.

So, you're saying Linode shouldn't provide certain cloud services, and Linode customers should be forced to use Linode's closest competitors to get those features on their Linode? It's not unreasonable to hope that a cloud services provider would have certain services that their competition offers.

It was worse before Linode began offering free incoming traffic, but S3 has some extra costs above and beyond what you'd have on a local Linode service. You need to pay for the bandwidth to send data to the S3 store (unlike a local Linode service might), and S3's outbound bandwidth costs are generally higher (double the price for Tokyo).



The vast majority of requests for elastic storage to date have been for slower cheaper network storage to supplement the very expensive but very fast local storage we have now. Unless cost is a concern, you can do exactly what you propose right now yourself using multiple linodes. If you don't want to take the effort (understandable), the use case still seems fairly limited, since it would only appeal to users who are exceeding the IOPS of existing Linode hardware.