|
Unfortunately, what you're looking for probably isn't possible. You can't just attach multiple writers to a block device, slap a standard filesystem on top, and expect it to work. Standard filesystem implementations are built on the assumption that they have exclusive access to the underlying block device. The block device interface provides no primitives suitable for concurrency control (no atomic compare-and-set, much less anything more sophisticated). Even if they did, you'd have to pretty much re-write the filesystem to make proper use of it. Even read-only multiple mounts are dodgy: the RO mounts aren't going to do cache coherence, and could trip up hard over intermediate states from the writer, but at least they won't corrupt the filesystem. Realistically, if you want multiple writers on a network block device, your application is going to have to go to the raw block device, and you get to figure out intra-client co-ordination on your own. This isn't actually terribly useful. As an ex-insider, the nonexistence of this feature is not due to technical difficulty (it should be pretty easy for EBS to let you have multiple writable attachments), it's because 0.1% of customers would find the feature actually useful, and the other 99.9% would use it to shoot themselves in the foot. If you want multiple machines accessing the same filesystem, you want a network attached filesystem. You can easily put samba / nfs-kernel-server / windows server in front of EBS. There are a few distributed filesystems, FOSS and propriety, if you need more scale. If you don't like any of the above, you're gonna have to build what you like yourself, or wait for somebody else to decide to build it for you. |
Yes, it is possible, and even in some cases (mine being one of them) desirable. I mentioned OCFS2, which is designed specifically for doing exactly that. When you do this right, it is an extremely high performance, simple way of sharing storage in a highly available manner.