Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

VaporStore – the design of a real-world cloud filesystem

1,224 views

Published on

Published in: Technology, News & Politics
  • Be the first to comment

VaporStore – the design of a real-world cloud filesystem

  1. 1. Outline Introduction Implementation Architecture Future improvements VaporStore the design of a real-world cloud filesystem Igor Bogicevic (igor.bogicevic@sbgenomics.com) July 3, 2010 Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  2. 2. Outline Introduction Implementation Architecture Future improvements Introduction So what do we need? And which options do we have? Implementation Challenges of implementing a cloud filesystem Requirements revisited Big Picture Terminology Architecture Major components Lifecycle of a file ”Lazy” updates Future improvements Stability and Security Features Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  3. 3. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  4. 4. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Has to support a ”Big Data” (easily 100MB-100GB per-file). Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  5. 5. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Has to support a ”Big Data” (easily 100MB-100GB per-file). Has to support a partial file uploads and possibility to continue file upload from the last uploaded fragment for large files. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  6. 6. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Has to support a ”Big Data” (easily 100MB-100GB per-file). Has to support a partial file uploads and possibility to continue file upload from the last uploaded fragment for large files. Has to support a concurrent clients and to act as a distributed filesystem. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  7. 7. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Has to support a ”Big Data” (easily 100MB-100GB per-file). Has to support a partial file uploads and possibility to continue file upload from the last uploaded fragment for large files. Has to support a concurrent clients and to act as a distributed filesystem. Simple but complete API to mimic a filesystem interface for easy integration with the applications. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  8. 8. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements So what do we need? A filesystem designed to be a persistence layer for a various Bioinformatic software that will be running in the cloud. Has to support a ”Big Data” (easily 100MB-100GB per-file). Has to support a partial file uploads and possibility to continue file upload from the last uploaded fragment for large files. Has to support a concurrent clients and to act as a distributed filesystem. Simple but complete API to mimic a filesystem interface for easy integration with the applications. Needs to have unix-like, or even finer grained access control. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  9. 9. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements And which options do we have? Plain S3 Objects - lacks support for objects bigger than 5GB and it doesn’t have a fine-grained access control. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  10. 10. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements And which options do we have? Plain S3 Objects - lacks support for objects bigger than 5GB and it doesn’t have a fine-grained access control. HDFS on top of S3 - probably the best match, however it doesn’t support security requirements as well as partial file uploads. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  11. 11. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements And which options do we have? Plain S3 Objects - lacks support for objects bigger than 5GB and it doesn’t have a fine-grained access control. HDFS on top of S3 - probably the best match, however it doesn’t support security requirements as well as partial file uploads. Various FUSE-to-S3 interfaces - either they don’t address the file-size, ACL or support for multiple clients (or are just toy-FS implementations). Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  12. 12. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements And which options do we have? Plain S3 Objects - lacks support for objects bigger than 5GB and it doesn’t have a fine-grained access control. HDFS on top of S3 - probably the best match, however it doesn’t support security requirements as well as partial file uploads. Various FUSE-to-S3 interfaces - either they don’t address the file-size, ACL or support for multiple clients (or are just toy-FS implementations). Something else - we’d love to know about any project that meets these requirements! Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  13. 13. Outline Introduction So what do we need? Implementation And which options do we have? Architecture Future improvements And which options do we have? Plain S3 Objects - lacks support for objects bigger than 5GB and it doesn’t have a fine-grained access control. HDFS on top of S3 - probably the best match, however it doesn’t support security requirements as well as partial file uploads. Various FUSE-to-S3 interfaces - either they don’t address the file-size, ACL or support for multiple clients (or are just toy-FS implementations). Something else - we’d love to know about any project that meets these requirements! DIY. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  14. 14. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Challenges of implementing a cloud filesystem ”Cloud filesystem” means nothing more than that content and metadata are not local and we don’t have a strict control over location of the data. Also, content of the files is not local to the filesystem metadata - i.e. filesystem structure, file ownership, etc. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  15. 15. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Challenges of implementing a cloud filesystem ”Cloud filesystem” means nothing more than that content and metadata are not local and we don’t have a strict control over location of the data. Also, content of the files is not local to the filesystem metadata - i.e. filesystem structure, file ownership, etc. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  16. 16. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Challenges of implementing a cloud filesystem ”Cloud filesystem” means nothing more than that content and metadata are not local and we don’t have a strict control over location of the data. Also, content of the files is not local to the filesystem metadata - i.e. filesystem structure, file ownership, etc. Latencies for remote read/write operations are few orders of a magnitude bigger than the latencies for operations on a local filesystem, yet we need to ensure decent performance especially in respect to metadata - filesystem exploration, modifications etc. need to happen in close-to-local speed. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  17. 17. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Challenges of implementing a cloud filesystem ”Cloud filesystem” means nothing more than that content and metadata are not local and we don’t have a strict control over location of the data. Also, content of the files is not local to the filesystem metadata - i.e. filesystem structure, file ownership, etc. Latencies for remote read/write operations are few orders of a magnitude bigger than the latencies for operations on a local filesystem, yet we need to ensure decent performance especially in respect to metadata - filesystem exploration, modifications etc. need to happen in close-to-local speed. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  18. 18. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Challenges of implementing a cloud filesystem ”Cloud filesystem” means nothing more than that content and metadata are not local and we don’t have a strict control over location of the data. Also, content of the files is not local to the filesystem metadata - i.e. filesystem structure, file ownership, etc. Latencies for remote read/write operations are few orders of a magnitude bigger than the latencies for operations on a local filesystem, yet we need to ensure decent performance especially in respect to metadata - filesystem exploration, modifications etc. need to happen in close-to-local speed. Working with the large files implies that we’ll need a mechanism to support a partial content uploads to handle the failures (connection drops, link outages, master server downtimes etc.). Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  19. 19. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  20. 20. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Does not have to be fast, however it needs to be reliable. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  21. 21. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Does not have to be fast, however it needs to be reliable. Must implement extensible ACL interface. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  22. 22. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Does not have to be fast, however it needs to be reliable. Must implement extensible ACL interface. Must support a partial file uploads and downloads. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  23. 23. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Does not have to be fast, however it needs to be reliable. Must implement extensible ACL interface. Must support a partial file uploads and downloads. Must support a maintenance downtimes. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  24. 24. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Requirements revisited Must support up to a few million files. Does not have to be fast, however it needs to be reliable. Must implement extensible ACL interface. Must support a partial file uploads and downloads. Must support a maintenance downtimes. Has to implement ”lazy” metadata persistence. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  25. 25. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Big Picture Vaporstore Server WEB FS Client TCP HTTP REST Client Command Interface Uploader/Sync Interface VS Shell Session Manager Credentials Storage File System Manager Block/Object Storage (S3) . Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  26. 26. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Terminology Filesystem - tree-based hierarchical structure containing files in many aspects similar to a common UNIX filesystem. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  27. 27. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Terminology Filesystem - tree-based hierarchical structure containing files in many aspects similar to a common UNIX filesystem. File/Node - individual element of filesystem that represent the atomic structure exposed to the end users, which means that users of VS can add, delete, manipulate the files. File itself contains the metadata describing various properties of the file (i.e. ownership, state, type, etc.) and block information and status. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  28. 28. Outline Challenges of implementing a cloud filesystem Introduction Requirements revisited Implementation Big Picture Architecture Terminology Future improvements Terminology Filesystem - tree-based hierarchical structure containing files in many aspects similar to a common UNIX filesystem. File/Node - individual element of filesystem that represent the atomic structure exposed to the end users, which means that users of VS can add, delete, manipulate the files. File itself contains the metadata describing various properties of the file (i.e. ownership, state, type, etc.) and block information and status. Block - represents the content of a file itself. Each file can contain many blocks scattered across the storage (i.e. S3). This construct is in a many aspects similar to the concept of a block in HDFS. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  29. 29. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Major components HTTP RESTful Interface - all operations on a filesystem structure are being performed through the RESTful interface and responses are wrapped in AVRO/JSON serialized messages. You can put, get, remove, update the files, or request information about it’s metadata. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  30. 30. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Major components HTTP RESTful Interface - all operations on a filesystem structure are being performed through the RESTful interface and responses are wrapped in AVRO/JSON serialized messages. You can put, get, remove, update the files, or request information about it’s metadata. TCP Command Interface - persistent connection used for a notifications and requests between server/client represented by simple AVRO/JSON message passing protocol. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  31. 31. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Major components HTTP RESTful Interface - all operations on a filesystem structure are being performed through the RESTful interface and responses are wrapped in AVRO/JSON serialized messages. You can put, get, remove, update the files, or request information about it’s metadata. TCP Command Interface - persistent connection used for a notifications and requests between server/client represented by simple AVRO/JSON message passing protocol. Session Manager - component used for authenticating the client sessions. Currently, one client can open only one session which might change in a future. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  32. 32. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Major components HTTP RESTful Interface - all operations on a filesystem structure are being performed through the RESTful interface and responses are wrapped in AVRO/JSON serialized messages. You can put, get, remove, update the files, or request information about it’s metadata. TCP Command Interface - persistent connection used for a notifications and requests between server/client represented by simple AVRO/JSON message passing protocol. Session Manager - component used for authenticating the client sessions. Currently, one client can open only one session which might change in a future. FileSystem Manager - component which performs filesystem updates on a persistent filesystem storage. Acts as a queue with a thread pool of a consumers which perform operations on a remote storage (i.e. S3). Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  33. 33. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Lifecycle of a file When we create the file through the HTTP RESTful interface, we’re creating a new node in filesystem structure containing it’s path, name, metadata and the list of the blocks. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  34. 34. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Lifecycle of a file When we create the file through the HTTP RESTful interface, we’re creating a new node in filesystem structure containing it’s path, name, metadata and the list of the blocks. If operation is successful, update is queued through the Filesystem manager and client starts uploading the block to the (S3) storage. Once the block is uploaded it sends the updates to the filesystem that a file’s block had been uploaded. After the file/node receives the update it schedules the update of it’s state to the persistent storage through the Filesystem Manager. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  35. 35. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements Lifecycle of a file When we create the file through the HTTP RESTful interface, we’re creating a new node in filesystem structure containing it’s path, name, metadata and the list of the blocks. If operation is successful, update is queued through the Filesystem manager and client starts uploading the block to the (S3) storage. Once the block is uploaded it sends the updates to the filesystem that a file’s block had been uploaded. After the file/node receives the update it schedules the update of it’s state to the persistent storage through the Filesystem Manager. After all blocks have been uploaded, we consider that this is now a valid file that can be accessed, and we schedule another update through the Filesystem manager to set it’s final state. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  36. 36. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements ”Lazy” updates All updates to a persistent storage are being done ”lazy” - this means that each update is first being done locally in memory and then scheduled for a transaction on a persistent store. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  37. 37. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements ”Lazy” updates All updates to a persistent storage are being done ”lazy” - this means that each update is first being done locally in memory and then scheduled for a transaction on a persistent store. This is both a performance optimization and a failure handling mechanism. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  38. 38. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements ”Lazy” updates All updates to a persistent storage are being done ”lazy” - this means that each update is first being done locally in memory and then scheduled for a transaction on a persistent store. This is both a performance optimization and a failure handling mechanism. Cost of this mechanism is that we will have to re-initialize the certain parts of the file upload that we’ve already done or that we might have a ”dirty” blocks that we need to clean up if the filesystem fails - i.e. if we don’t update file’s information that certain blocks have been uploaded, we will need to upload them again to a storage, or if we delete a file but we don’t remove the blocks from a storage, we will have a ”dirty” blocks. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  39. 39. Outline Introduction Major components Implementation Lifecycle of a file Architecture ”Lazy” updates Future improvements ”Lazy” updates All updates to a persistent storage are being done ”lazy” - this means that each update is first being done locally in memory and then scheduled for a transaction on a persistent store. This is both a performance optimization and a failure handling mechanism. Cost of this mechanism is that we will have to re-initialize the certain parts of the file upload that we’ve already done or that we might have a ”dirty” blocks that we need to clean up if the filesystem fails - i.e. if we don’t update file’s information that certain blocks have been uploaded, we will need to upload them again to a storage, or if we delete a file but we don’t remove the blocks from a storage, we will have a ”dirty” blocks. Yes, we can do this smarter in order to avoid this problems - in a future releases. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  40. 40. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Stability and Security Stability - it is fully featured except the ACLs, however it’s not well tested and not production-ready. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  41. 41. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Stability and Security Stability - it is fully featured except the ACLs, however it’s not well tested and not production-ready. Security - currently a client needs to get S3 credential from a server after it’s authenticated, however if we put the ”content proxy” in between client and S3 we can outsorce direct S3 access to a proxy. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  42. 42. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Stability and Security Stability - it is fully featured except the ACLs, however it’s not well tested and not production-ready. Security - currently a client needs to get S3 credential from a server after it’s authenticated, however if we put the ”content proxy” in between client and S3 we can outsorce direct S3 access to a proxy. Partitioning and HA - support for multiple servers handling different branches of a filesystem tree HA for each partition Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  43. 43. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Stability and Security Stability - it is fully featured except the ACLs, however it’s not well tested and not production-ready. Security - currently a client needs to get S3 credential from a server after it’s authenticated, however if we put the ”content proxy” in between client and S3 we can outsorce direct S3 access to a proxy. Partitioning and HA - support for multiple servers handling different branches of a filesystem tree HA for each partition Bursting support - dropping the requests if we can’t handle the load. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  44. 44. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  45. 45. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Smarter ”lazy” updates . Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  46. 46. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Smarter ”lazy” updates . Torrent support for a ”content proxy” - just an idea, but might make a sense. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  47. 47. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Smarter ”lazy” updates . Torrent support for a ”content proxy” - just an idea, but might make a sense. Support for AWS import/export. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  48. 48. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Smarter ”lazy” updates . Torrent support for a ”content proxy” - just an idea, but might make a sense. Support for AWS import/export. Richer client support - besides API and shell, we’ll add a client service that will perform dropbox-like synchronization. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem
  49. 49. Outline Introduction Stability and Security Implementation Features Architecture Future improvements Features Various storage backends - it’s currently using S3, however it could use pretty much anything... anything that makes sense. Smarter ”lazy” updates . Torrent support for a ”content proxy” - just an idea, but might make a sense. Support for AWS import/export. Richer client support - besides API and shell, we’ll add a client service that will perform dropbox-like synchronization. External queues support - configurable support using JMS instead of internal queue. Igor Bogicevic (igor.bogicevic@sbgenomics.com) VaporStore the design of a real-world cloud filesystem

×