gourao

That is a fair point, and most of the end users we work with are using k8s and mesos to deploy and run the applications. The issue I have with the article is that it assumes that a packaging tool is what defines the rest of your operational procedures. They are two different things, as they always have been in Linux.

Docker is a packaging tool. How you chose to deploy your software package has nothing to do with your operational and DB administration procedures. Mixing the two topics is very confusing.

Interesting thought, however I think that the existing graph driver file systems are not actually an "image layer file system"... instead they are a general purpose file systems that are being used to store images.

For example, what one wants with launching multiple instances of an image is to be able to clone the image. Today, to accomplish that, file system snapshots are used to simulate this feature. And that is where a lot of the problems start happening. LCFS does things purpose built for these use cases.

LCFS is not yet being used in production as far as I know

We started building this because there are a lot of issues running containers in production, specifically around image space and inode management and also with page cash usage.

This file system was specifically designed to address memory and storage management of container images

Hi, I am one of the contributors on this project, and happy to answer any questions... LCFS will also be supporting the snapshot driver discussed here - https://github.com/docker/containerd/pull/484.

Currently, the install experience is not the greatest... We rely on the Docker v2 plugin interface and that is still in beta. We are working with the Docker team to help us smooth out some of these rough edges.

LCFS will also support other container formats and any help from the community is much appreciated.

The tests were run against a local repository to remove network variability.

Your comment on using docker pull to benchmark a file system perplexes me. This is not a general purpose file system, it is purpose built for only one use case - the graph driver.

The good news is that this is all open source, so if there is a specific concern, this should be opened as an issue on the github. The claims are also easy to validate (or refute)... since you can just run it on your own system. Please do share that experience on github, as we are genuinely interested in making this successful for everyone.

The install setup experience is definitely something worth pointing out. This is an area where it is not as smooth as it should be, but we are working with Docker to work on those issues. We need a richer set of interfaces to make the v2 plugin interface work... note that the v2 plugin interface is still in beta. This is in no was a finished project, we are working with others in the community to see this through.