3 ms·

Disclosure: I work for OpenEBS project Torus was intending to write distributed block storge that is container native. Metadata management using key value (KV

Disclosure: I work for OpenEBS project Torus was intending to write distributed block storge that is container native. Metadata management using key value (KV / etcd) method is increases the complexity and not new. Ceph tried it. OpenEBS uses a novel approch, linux sparse files for managing the blocks of a volume. Fork of Rancher longhorn. The issue of managing the large scale distributed block storage metadata is solved easily throught he management of the files (not blocks). https://blog.openebs.io/torus-from-coreos-steps-aside-as-cloud-native-storage-platform-what-now-2375e7f5b145#.fslj3rwsg https://blog.openebs.io/torus-from-coreos-steps-aside-as-clo...

fh973 10y ago
What I don't get around the new efforts around container-native storage: if you decide to build a new container-native storage system, why would you aim for block storage and not file storage? Block storage is not exactly a great fit for containers as you can't access its file systems from multiple hosts and fail-over is a hassle (forced remount, fsck).
- umamukkara 10y ago
  Container native storage has two aspects. One, the storage that container uses, (Like Docker uses Device Mapper, Overlay2 etc.) and two, the persistent storage that the applications inside containers need. Both of them need to be truly container native. Portworx is attempting LCFS to provide a container native storage for containers itself https://github.com/portworx/lcfs https://github.com/portworx/lcfs. So, you are right. You would need a container-native storage (file system for Docker) for running containers. OpenEBS is targeting providing containerized storage (persistent+block storage) for applications in containers. OpenEBS builds a storage volume as a container and presents the volume-container as part of the K8s POD. This way the the storage persistence problems are resolved by K8S orchestration ingelligence written for application PODs. Ofcouse, OpenEBS containers will use LCFS when it is ready.
- wmf 10y ago
  File systems are much harder than block storage due to the large amount of metadata and the consistency/durability requirements for metadata. So a lot of systems just build block storage and format ext4 on top or put NFS+ZFS on top (but that's not very distributed).

fh973 10y ago

What I don't get around the new efforts around container-native storage: if you decide to build a new container-native storage system, why would you aim for block storage and not file storage? Block storage is not exactly a great fit for containers as you can't access its file systems from multiple hosts and fail-over is a hassle (forced remount, fsck).

umamukkara 10y ago
Container native storage has two aspects. One, the storage that container uses, (Like Docker uses Device Mapper, Overlay2 etc.) and two, the persistent storage that the applications inside containers need. Both of them need to be truly container native. Portworx is attempting LCFS to provide a container native storage for containers itself https://github.com/portworx/lcfs https://github.com/portworx/lcfs. So, you are right. You would need a container-native storage (file system for Docker) for running containers. OpenEBS is targeting providing containerized storage (persistent+block storage) for applications in containers. OpenEBS builds a storage volume as a container and presents the volume-container as part of the K8s POD. This way the the storage persistence problems are resolved by K8S orchestration ingelligence written for application PODs. Ofcouse, OpenEBS containers will use LCFS when it is ready.
wmf 10y ago
File systems are much harder than block storage due to the large amount of metadata and the consistency/durability requirements for metadata. So a lot of systems just build block storage and format ext4 on top or put NFS+ZFS on top (but that's not very distributed).